* Re: linux-next: build warning in Linus' tree
From: Geert Uytterhoeven @ 2016-10-29 21:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, linux-next, Linux Kernel Mailing List
In-Reply-To: <CA+55aFwDL2_Ecuei4tYLH34RDmOba_COfr5JajasvYXA++yUgA@mail.gmail.com>
Hi Linus,
On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
>> does seem to disable a lot of build-time testing.
>
> Actually, we should probably just make the MEMORY_HOTPLUG dependency be
>
> depends on COMPILE_TEST || !KASAN
>
> since the memory-hotplug code should still *build* with KASAN, it just
> doesn't work. That's exactly what the COMPILE_TEST config option is
> there for - to get build coverage even for things that aren't
> necessarily sane to run.
In what way does it not work? Does it crash?
People do run COMPILE_TEST=y/allmodconfig kernels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: mmotm 2016-10-27-18-27 uploaded
From: Paul Gortmaker @ 2016-10-30 18:15 UTC (permalink / raw)
To: Andrew Morton
Cc: mm-commits, LKML, linux-mm, linux-fsdevel,
linux-next@vger.kernel.org, Stephen Rothwell, Michal Hocko,
broonie
In-Reply-To: <5812a9b6.OlAMBhewokz9/Mou%akpm@linux-foundation.org>
On Thu, Oct 27, 2016 at 9:28 PM, <akpm@linux-foundation.org> wrote:
> The mm-of-the-moment snapshot 2016-10-27-18-27 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
Just a heads up:
Somehow one of the akpm commits as it appears in linux-next has had
spaces replaced with garbage chars:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/scripts/get_maintainer.pl?id=b67071653d3fc9f9b73aab3e7978f060728bf392
Paul.
--
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
>
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE-yyyy-mm-dd-hh-mm-ss. Both contain the string yyyy-mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
>
> This tree is partially included in linux-next. To see which patches are
> included in linux-next, consult the `series' file. Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
>
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko. It contains the patches which are between the
> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> file, http://www.ozlabs.org/~akpm/mmotm/series.
>
>
> A full copy of the full kernel tree with the linux-next and mmotm patches
> already applied is available through git within an hour of the mmotm
> release. Individual mmotm releases are tagged. The master branch always
> points to the latest release, so it's constantly rebasing.
>
> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
>
[...]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: build warning in Linus' tree
From: Andrey Ryabinin @ 2016-10-30 19:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Linus Torvalds
Cc: Stephen Rothwell, Alexander Potapenko, Dmitry Vyukov, linux-next,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdVSqTkockvOBChTfGt9PJBZiEqDiUAAcCSas2x9t6mD_g@mail.gmail.com>
On 10/30/2016 12:29 AM, Geert Uytterhoeven wrote:
> Hi Linus,
>
> On Fri, Oct 28, 2016 at 1:01 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Oct 27, 2016 at 3:48 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> I wonder if we should make KASAN depend on !COMPILE_TEST, because it
>>> does seem to disable a lot of build-time testing.
>>
>> Actually, we should probably just make the MEMORY_HOTPLUG dependency be
>>
>> depends on COMPILE_TEST || !KASAN
>>
>> since the memory-hotplug code should still *build* with KASAN, it just
>> doesn't work. That's exactly what the COMPILE_TEST config option is
>> there for - to get build coverage even for things that aren't
>> necessarily sane to run.
>
> In what way does it not work? Does it crash?
It doesn't crash, it will fail to online hotpluged memory.
Originally, we didn't have build-time dependency at all.
It appeared quite recently in 1e185736d214("mm: disable CONFIG_MEMORY_HOTPLUG when KASAN is enabled")
> People do run COMPILE_TEST=y/allmodconfig kernels.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* Re: linux-next: bad commit in the sunxi tree
From: Michael Ellerman @ 2016-10-31 2:59 UTC (permalink / raw)
To: Maxime Ripard, Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20161027204137.ef6kxlzyvftcdomn@lukather>
Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> On Thu, Oct 27, 2016 at 10:42:25AM +1100, Stephen Rothwell wrote:
>> On Tue, 25 Oct 2016 11:44:09 +0200 Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> > On Tue, Oct 25, 2016 at 09:22:55AM +1100, Stephen Rothwell wrote:
>> > > In today's sunxi tree
>> > > (git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git#sunxi/for-next)
>> > > I noticed that commit
>> > >
>> > > 3861b711f8b5 ("ARM: sun5i: chip: add a node for the w1 gpio controller")
>> > >
>> > > has no Signed-off-by from its committer.
>> >
>> > Thanks, this has been fixed.
>> >
>> > Just out of curiosity, what command do you run to catch this?
>>
>> None :-) I look at the differences in each tree as I fetch it and
>> just happen to notice some of these sometimes. I should have a git
>> hook to check that there is a Signed-off-by for the author and
>> committer, but I would have to invest some time to figure out how :-)
>
> Ok, that's actually the real question I had in mind, if you had a hook
> I could use in order to avoid that kind of things in the future :)
I don't run a hook, but I have a separate script which does checks like
that. I've pulled out the Signed-off-by check into a script below, which
might work for you, or at least give you something to start from.
cheers
#!/bin/bash
function check_sob_by_committer
{
local commit=$1
git rev-parse --verify ${commit}^2 > /dev/null 2>&1
if [[ $? -eq 0 ]]; then
# It has at least 2 parents, ie. it's a merge
# We don't sign off merges, so we're done
return
fi
committer=$(git log -1 --format='%cn <%ce>' $commit)
git log -1 --format=%b $commit | grep "Signed-off-by: $committer" > /dev/null
if [[ $? -ne 0 ]]; then
echo " Not SOB committer '$committer'"
return 1
fi
return 0
}
check_sob_by_committer $1
exit $?
^ permalink raw reply
* Re: linux-next: bad commit in the sunxi tree
From: Stephen Rothwell @ 2016-10-31 14:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Maxime Ripard, linux-next, linux-kernel
In-Reply-To: <8737jd2pg6.fsf@concordia.ellerman.id.au>
Hi Michael,
On Mon, 31 Oct 2016 13:59:53 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> I don't run a hook, but I have a separate script which does checks like
> that. I've pulled out the Signed-off-by check into a script below, which
> might work for you, or at least give you something to start from.
Turns out that there is no hook that gets runa ta fetch time, so thanks
for this I will adapt this into my "fetch the trees" script.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: mmotm 2016-10-27-18-27 uploaded
From: Valdis.Kletnieks @ 2016-10-31 20:37 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Andrew Morton, mm-commits, LKML, linux-mm, linux-fsdevel,
linux-next@vger.kernel.org, Stephen Rothwell, Michal Hocko,
broonie
In-Reply-To: <CAP=VYLqNv8p_ojkcjeWCN-nMumDg296UkV1b460KDHAXOHZSEA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Sun, 30 Oct 2016 14:15:30 -0400, Paul Gortmaker said:
> On Thu, Oct 27, 2016 at 9:28 PM, <akpm@linux-foundation.org> wrote:
> > The mm-of-the-moment snapshot 2016-10-27-18-27 has been uploaded to
> >
> > http://www.ozlabs.org/~akpm/mmotm/
>
> Just a heads up:
>
> Somehow one of the akpm commits as it appears in linux-next has had
> spaces replaced with garbage chars:
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/scripts/get_maintainer.pl?id=b67071653d3fc9f9b73aab3e7978f060728bf392
How... special. They're 0xA0 non-breaking-space chars. Somebody's
editor was obviously in the wrong mode. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree
From: Liviu Dudau @ 2016-11-03 17:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Vetter, Intel Graphics, linux-kernel, DRI, linux-next
In-Reply-To: <20161025112044.1a866eaa@canb.auug.org.au>
On Tue, Oct 25, 2016 at 11:20:44AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
Hi Stephen,
>
> Today's linux-next merge of the mali-dp tree got a conflict in:
>
> drivers/gpu/drm/arm/malidp_planes.c
>
> between commit:
>
> ea0e1ce20f73 ("drm/arm: Use per-plane rotation property")
>
> from the drm-misc tree and commit:
>
> 9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation")
>
> from the mali-dp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Sorry for delay in answering, I was on holiday.
I have revamped the mali-dp tree and rebased it on the newer
version of drm-next (which includes the drm-misc change) and pushed the
updated patch in my tree.
Best regards,
Liviu
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/arm/malidp_planes.c
> index abaca03b9d36,9020c0d8399c..000000000000
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de
> if (ret < 0)
> goto cleanup;
>
> + drm_plane_helper_add(&plane->base,
> + &malidp_de_plane_helper_funcs);
> + plane->hwdev = malidp->dev;
> + plane->layer = &map->layers[i];
> +
> + /* Skip the features which the SMART layer doesn't have */
> + if (id == DE_SMART)
> + continue;
> +
> - if (!drm->mode_config.rotation_property) {
> + /* SMART layer can't be rotated */
> + if (id != DE_SMART) {
> unsigned long flags = DRM_ROTATE_0 |
> DRM_ROTATE_90 |
> DRM_ROTATE_180 |
> DRM_ROTATE_270 |
> DRM_REFLECT_X |
> DRM_REFLECT_Y;
> - drm->mode_config.rotation_property =
> - drm_mode_create_rotation_property(drm, flags);
> + drm_plane_create_rotation_property(&plane->base,
> + DRM_ROTATE_0,
> + flags);
> }
>
> - drm_plane_helper_add(&plane->base,
> - &malidp_de_plane_helper_funcs);
> - plane->hwdev = malidp->dev;
> - plane->layer = &map->layers[i];
> - if (drm->mode_config.rotation_property)
> - drm_object_attach_property(&plane->base.base,
> - drm->mode_config.rotation_property,
> - DRM_ROTATE_0);
> -
> + malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
> + plane->layer->base + MALIDP_LAYER_COMPOSE);
> }
>
> kfree(formats);
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree
From: Stephen Rothwell @ 2016-11-04 5:38 UTC (permalink / raw)
To: Liviu Dudau; +Cc: Daniel Vetter, Intel Graphics, linux-kernel, DRI, linux-next
In-Reply-To: <20161103171958.GA17265@e106497-lin.cambridge.arm.com>
Hi Liviu,
On Thu, 3 Nov 2016 17:19:58 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> I have revamped the mali-dp tree and rebased it on the newer
> version of drm-next (which includes the drm-misc change) and pushed the
> updated patch in my tree.
Thanks for that. However, several of the commits in your tree now have
no Signed-off-by from you as the committer :-(
--
Cheers,
Stephen Rothwell
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree
From: Liviu Dudau @ 2016-11-04 15:48 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Vetter, Intel Graphics, linux-kernel, DRI, linux-next
In-Reply-To: <20161104163854.2c416e21@canb.auug.org.au>
On Fri, Nov 04, 2016 at 04:38:54PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Thu, 3 Nov 2016 17:19:58 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >
> > I have revamped the mali-dp tree and rebased it on the newer
> > version of drm-next (which includes the drm-misc change) and pushed the
> > updated patch in my tree.
>
> Thanks for that. However, several of the commits in your tree now have
> no Signed-off-by from you as the committer :-(
Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
alone should be good. Baoyou's patch is in my tree to stop him repeatedly
send me the same patch over and over again :) But yes, I will add my
Signed-off-by for that one.
Many thanks,
Liviu
>
> --
> Cheers,
> Stephen Rothwell
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree
From: Stephen Rothwell @ 2016-11-04 16:55 UTC (permalink / raw)
To: Liviu Dudau
Cc: Daniel Vetter, Intel Graphics, DRI, linux-next, linux-kernel,
Ville Syrjälä, Brian Starkey
In-Reply-To: <20161104154802.GC17265@e106497-lin.cambridge.arm.com>
Hi Liviu,
On Fri, 4 Nov 2016 15:48:02 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> send me the same patch over and over again :) But yes, I will add my
> Signed-off-by for that one.
Sorry, but this is not sufficient. Please read section 11 of
Documentation/SubmittingPatches (or
Documentation/process/submitting-patches.rst where it has been moved
recently). If you are in the path of a patch to Linus, you must add a
Signed-off-by line, and as the person who committed those patches to
the tree, you are in the path.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree
From: Liviu Dudau @ 2016-11-04 16:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Vetter, Intel Graphics, linux-kernel, DRI, linux-next
In-Reply-To: <20161105035503.4e7f39a6@canb.auug.org.au>
On Sat, Nov 05, 2016 at 03:55:03AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Fri, 4 Nov 2016 15:48:02 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >
> > Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> > alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> > send me the same patch over and over again :) But yes, I will add my
> > Signed-off-by for that one.
>
> Sorry, but this is not sufficient. Please read section 11 of
> Documentation/SubmittingPatches (or
> Documentation/process/submitting-patches.rst where it has been moved
> recently). If you are in the path of a patch to Linus, you must add a
> Signed-off-by line, and as the person who committed those patches to
> the tree, you are in the path.
Thanks for correcting me. I will add my Signed-off-bys to the relevant
patches.
Best regards,
Liviu
> --
> Cheers,
> Stephen Rothwell
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* linux-next: no release today
From: Stephen Rothwell @ 2016-11-07 5:16 UTC (permalink / raw)
To: linux-next; +Cc: LKML
Hi all,
There will be no linx-next release today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-11-08 1:25 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, WANG Cong, Johannes Berg
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/netlink/genetlink.c
between commit:
00ffc1ba02d8 ("genetlink: fix a memory leak on error path")
from the net tree and commit:
2ae0f17df1cd ("genetlink: use idr to track families")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/netlink/genetlink.c
index 49c28e8ef01b,bbd3bff885a1..000000000000
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@@ -402,11 -360,17 +360,17 @@@ int genl_register_family(struct genl_fa
} else
family->attrbuf = NULL;
+ family->id = idr_alloc(&genl_fam_idr, family,
+ start, end + 1, GFP_KERNEL);
+ if (family->id < 0) {
+ err = family->id;
- goto errout_locked;
++ goto errout_free;
+ }
+
err = genl_validate_assign_mc_groups(family);
if (err)
- goto errout_free;
+ goto errout_remove;
- list_add_tail(&family->family_list, genl_family_chain(family->id));
genl_unlock_all();
/* send all events */
@@@ -417,14 -381,13 +381,15 @@@
return 0;
+ errout_remove:
+ idr_remove(&genl_fam_idr, family->id);
+errout_free:
+ kfree(family->attrbuf);
errout_locked:
genl_unlock_all();
- errout:
return err;
}
- EXPORT_SYMBOL(__genl_register_family);
+ EXPORT_SYMBOL(genl_register_family);
/**
* genl_unregister_family - unregister generic netlink family
^ permalink raw reply
* linux-next: manual merge of the rdma-leon-test tree with the net-next tree
From: Stephen Rothwell @ 2016-11-08 2:06 UTC (permalink / raw)
To: Leon Romanovsky, David Miller, Networking
Cc: linux-next, linux-kernel, David Ahern
Hi Leon,
Today's linux-next merge of the rdma-leon-test tree got a conflict in:
drivers/infiniband/core/roce_gid_mgmt.c
between commit:
453d39329ad0 ("IB/core: Flip to the new dev walk API")
from the net-next tree and commit:
e4b4d6b5d8c2 ("IB/core: Remove debug prints after allocation failure")
from the rdma-leon-test tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/core/roce_gid_mgmt.c
index 3a64a0881882,c86ddcea7675..000000000000
--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@@ -437,28 -434,6 +434,26 @@@ static void callback_for_addr_gid_devic
&parsed->gid_attr);
}
+struct upper_list {
+ struct list_head list;
+ struct net_device *upper;
+};
+
+static int netdev_upper_walk(struct net_device *upper, void *data)
+{
+ struct upper_list *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ struct list_head *upper_list = data;
+
- if (!entry) {
- pr_info("roce_gid_mgmt: couldn't allocate entry to delete ndev\n");
++ if (!entry)
+ return 0;
- }
+
+ list_add_tail(&entry->list, upper_list);
+ dev_hold(upper);
+ entry->upper = upper;
+
+ return 0;
+}
+
static void handle_netdev_upper(struct ib_device *ib_dev, u8 port,
void *cookie,
void (*handle_netdev)(struct ib_device *ib_dev,
^ permalink raw reply
* linux-next: manual merge of the kspp tree with Linus' tree
From: Stephen Rothwell @ 2016-11-08 2:31 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-next, linux-kernel, Emese Revfy
Hi Kees,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the kspp tree got a conflict in:
mm/page_alloc.c
scripts/gcc-plugins/latent_entropy_plugin.c
between commits:
38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
0766f788eb72 ("latent_entropy: Mark functions with __latent_entropy")
58bea4144d23 ("latent_entropy: Fix wrong gcc code generation with 64 bit variables")
from Linus' tree and commits:
2a5448668a3c ("gcc-plugins: Add latent_entropy plugin")
09dd109d8241 ("latent_entropy: Mark functions with __latent_entropy")
from the kspp tree.
I fixed it up (I used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
Kees, maybe you could clean up the kspp tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the sound-asoc tree
From: Stephen Rothwell @ 2016-11-08 2:47 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood; +Cc: linux-next, linux-kernel, Chen-Yu Tsai
Hi all,
After merging the sound-asoc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
sound/soc/sunxi/sun4i-codec.c:1188:2: error: unknown field 'has_reset' specified in initializer
.has_reset = true,
^
sound/soc/sunxi/sun4i-codec.c:1188:15: warning: excess elements in struct initializer
.has_reset = true,
^
sound/soc/sunxi/sun4i-codec.c:1188:15: note: (near initialization for 'sun6i_a31_codec_quirks')
Caused by commit
8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31 playback through headphone output")
I have used the sound-asoc tree from next-20161028 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the sound-asoc tree
From: Chen-Yu Tsai @ 2016-11-08 3:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mark Brown, Liam Girdwood, linux-next, linux-kernel, Chen-Yu Tsai
In-Reply-To: <20161108134723.3b4fc5d5@canb.auug.org.au>
Hi,
On Tue, Nov 8, 2016 at 10:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> sound/soc/sunxi/sun4i-codec.c:1188:2: error: unknown field 'has_reset' specified in initializer
> .has_reset = true,
> ^
> sound/soc/sunxi/sun4i-codec.c:1188:15: warning: excess elements in struct initializer
> .has_reset = true,
> ^
> sound/soc/sunxi/sun4i-codec.c:1188:15: note: (near initialization for 'sun6i_a31_codec_quirks')
>
> Caused by commit
>
> 8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31 playback through headphone output")
>
> I have used the sound-asoc tree from next-20161028 for today.
sound-asoc is missing patch
ASoC: sun4i-codec: Add support for optional reset control to quirks
http://www.spinics.net/lists/alsa-devel/msg56289.html
which commit 8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31 playback
through headphone output") depends on. This was part of the same series that
I posted:
http://www.spinics.net/lists/alsa-devel/msg56283.html
A new version of the remaining patches was posted yesterday:
http://www.spinics.net/lists/alsa-devel/msg56443.html
The build failure should be resolved once Mark merges the remaining patches,
though some reordering might be needed to maintain bisectability.
Regards
ChenYu
^ permalink raw reply
* linux-next: build failure after merge of the block tree
From: Stephen Rothwell @ 2016-11-08 3:21 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig
Hi Jens,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
block/blk-flush.c: In function 'flush_data_end_io':
block/blk-flush.c:369:20: error: 'REQ_STARTED' undeclared (first use in this function)
rq->cmd_flags &= ~REQ_STARTED;
^
Caused by commit
e806402130c9 ("block: split out request-only flags into a new namespace")
interacting with commit
94d7dea448fa ("block: flush: fix IO hang in case of flood fua req")
from Linus' tree (v4.9-rc3).
I have applied the following merge fix patch for today (I don't know if
this is correct, but it does build):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Nov 2016 14:08:03 +1100
Subject: [PATCH] block: fixup for "split out request-only flags into a new namespace"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
block/blk-flush.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 0a02e765fa14..0bef7432d725 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -366,7 +366,7 @@ static void flush_data_end_io(struct request *rq, int error)
elv_completed_request(q, rq);
/* for avoiding double accounting */
- rq->cmd_flags &= ~REQ_STARTED;
+ rq->rq_flags &= ~RQF_STARTED;
/*
* After populating an empty queue, kick it to avoid stall. Read
--
2.10.2
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: linux-next: build failure after merge of the block tree
From: Jens Axboe @ 2016-11-08 3:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig
In-Reply-To: <20161108142140.3232b3b2@canb.auug.org.au>
On 11/07/2016 08:21 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-flush.c: In function 'flush_data_end_io':
> block/blk-flush.c:369:20: error: 'REQ_STARTED' undeclared (first use in this function)
> rq->cmd_flags &= ~REQ_STARTED;
> ^
>
> Caused by commit
>
> e806402130c9 ("block: split out request-only flags into a new namespace")
>
> interacting with commit
>
> 94d7dea448fa ("block: flush: fix IO hang in case of flood fua req")
>
> from Linus' tree (v4.9-rc3).
>
> I have applied the following merge fix patch for today (I don't know if
> this is correct, but it does build):
It's correct, it needs to be applied if merging with master. It will
throw a real conflict as well, but this one tends to fly under the radar
since it merges cleanly.
I'll merge master into my for-next so you don't have to carry extra
patches for this.
--
Jens Axboe
^ permalink raw reply
* linux-next: manual merge of the tip tree with the drm-intel tree
From: Stephen Rothwell @ 2016-11-08 4:25 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Daniel Vetter, Intel Graphics, DRI
Cc: linux-next, linux-kernel, Chris Wilson
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_shrinker.c
between commits:
1233e2db199d ("drm/i915: Move object backing storage manipulation to its own locking")
from the drm-intel tree and commit:
3ab7c086d5ec ("locking/drm: Kill mutex trickery")
c7faee2109f9 ("locking/drm: Fix i915_gem_shrinker_lock() locking")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/i915_gem_shrinker.c
index a6fc1bdc48af,e9bd2a81d03a..000000000000
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@@ -35,33 -35,6 +35,15 @@@
#include "i915_drv.h"
#include "i915_trace.h"
- static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
- {
- if (!mutex_is_locked(mutex))
- return false;
-
- #if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_MUTEX_SPIN_ON_OWNER)
- return mutex->owner == task;
- #else
- /* Since UP may be pre-empted, we cannot assume that we own the lock */
- return false;
- #endif
- }
-
+static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
+{
- if (!mutex_trylock(&dev->struct_mutex)) {
- if (!mutex_is_locked_by(&dev->struct_mutex, current))
- return false;
-
- *unlock = false;
- } else {
- *unlock = true;
- }
++ if (!mutex_trylock(&dev->struct_mutex))
++ return false;
+
++ *unlock = true;
+ return true;
+}
+
static bool any_vma_pinned(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma;
^ permalink raw reply
* linux-next: manual merge of the tty tree with the jc_docs tree
From: Stephen Rothwell @ 2016-11-08 5:30 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet
Cc: linux-next, linux-kernel, Mauro Carvalho Chehab, Jiri Slaby
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in:
Documentation/VGA-softcursor.txt
between commits:
27641b953c54 ("Documentation/VGA-softcursor.txt: convert to ReST markup")
9d85025b0418 ("docs-rst: create an user's manual book")
from the jc_docs tree and commit:
b9c8b7fc252c ("vgacon: remove prehistoric macros")
from the tty tree.
I fixed it up (I deleted it - since 9d85025b0418 moved it - but that
means it may need fixing up in its new location to match any relevant
changes in b9c8b7fc252c) and can carry the fix as necessary. This is
now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the scsi tree with the block tree
From: Stephen Rothwell @ 2016-11-08 5:48 UTC (permalink / raw)
To: James Bottomley, Jens Axboe
Cc: linux-next, linux-kernel, Christoph Hellwig, Gilad Broner,
Martin K. Petersen, Subhash Jadavani
Hi James,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/ufs/ufshcd.c
between commit:
e806402130c9 ("block: split out request-only flags into a new namespace")
from the block tree and commit:
2266d5678ad1 ("scsi: ufs: fix sense buffer size to 18 bytes")
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/ufs/ufshcd.c
index cf549871c1ee,304adce3bdbe..000000000000
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@@ -5589,8 -5642,8 +5642,8 @@@ ufshcd_send_request_sense(struct ufs_hb
}
ret = scsi_execute_req_flags(sdp, cmd, DMA_FROM_DEVICE, buffer,
- SCSI_SENSE_BUFFERSIZE, NULL,
+ UFSHCD_REQ_SENSE_SIZE, NULL,
- msecs_to_jiffies(1000), 3, NULL, REQ_PM);
+ msecs_to_jiffies(1000), 3, NULL, 0, RQF_PM);
if (ret)
pr_err("%s: failed with err %d\n", __func__, ret);
^ permalink raw reply
* linux-next: manual merge of the libata tree with the block tree
From: Stephen Rothwell @ 2016-11-08 5:58 UTC (permalink / raw)
To: Tejun Heo, Jens Axboe
Cc: linux-next, linux-kernel, Adam Manzanares, Christoph Hellwig
Hi Tejun,
Today's linux-next merge of the libata tree got a conflict in:
block/blk-core.c
between commits:
e806402130c9 ("block: split out request-only flags into a new namespace")
ef295ecf090d ("block: better op and flags encoding")
from the block tree and commit:
5dc8b362a237 ("block: Add iocontext priority to request")
from the libata tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@@ -1152,11 -1153,11 +1152,12 @@@ static struct request *__get_request(st
blk_rq_init(q, rq);
blk_rq_set_rl(rq, rl);
+ blk_rq_set_prio(rq, ioc);
- req_set_op_attrs(rq, op, op_flags | REQ_ALLOCED);
+ rq->cmd_flags = op;
+ rq->rq_flags = rq_flags;
/* init elvpriv */
- if (op_flags & REQ_ELVPRIV) {
+ if (rq_flags & RQF_ELVPRIV) {
if (unlikely(et->icq_cache && !icq)) {
if (ioc)
icq = ioc_create_icq(ioc, q, gfp_mask);
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Cong Wang @ 2016-11-08 6:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, linux-next, LKML, Johannes Berg
In-Reply-To: <20161108122537.40fa6e58@canb.auug.org.au>
On Mon, Nov 7, 2016 at 5:25 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/netlink/genetlink.c
>
> between commit:
>
> 00ffc1ba02d8 ("genetlink: fix a memory leak on error path")
>
> from the net tree and commit:
>
> 2ae0f17df1cd ("genetlink: use idr to track families")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Looks good to me.
Thanks!
^ permalink raw reply
* linux-next: build failure after merge of the rtc tree
From: Stephen Rothwell @ 2016-11-08 6:41 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-next, linux-kernel, Paul Cercueil
Hi Alexandre,
After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
Caused by commit
f9eb69d1ae2f ("rtc: jz4740: Add support for acting as the system power controller")
I have used the rtc tree from next-20161028 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox