* Re: linux-next: manual merge of the block tree with the vfs tree
From: Ming Lei @ 2016-12-12 2:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, Al Viro, linux-next@vger.kernel.org,
Linux Kernel Mailing List, Christoph Hellwig
In-Reply-To: <20161212123140.2408fefb@canb.auug.org.au>
On Mon, Dec 12, 2016 at 9:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in:
>
> fs/logfs/dev_bdev.c
>
> between commit:
>
> 6b4fbde3b979 ("logfs: remove from tree")
>
> from the vfs tree and commitis:
>
> 3a83f4677539 ("block: bio: pass bvec table to bio_init()")
> 739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
> d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
> c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
> 05aea81b4bc9 ("fs: logfs: remove unnecesary check")
>
> from the block tree.
>
> I fixed it up (I removed the file) 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 every time the logfs changes have been posted in fsdev mail list.
--
Ming Lei
^ permalink raw reply
* Re: linux-next: manual merge of the block tree with the vfs tree
From: Al Viro @ 2016-12-12 1:44 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, linux-next, linux-kernel, Ming Lei, Christoph Hellwig
In-Reply-To: <20161212123140.2408fefb@canb.auug.org.au>
On Mon, Dec 12, 2016 at 12:31:40PM +1100, Stephen Rothwell wrote:
> Al: that vfs tree commit has a bad email address for Christoph in it :-(
Gyah... OK, will fix (the bulk of the diff, of course, had been regenerated
while commit message came from his old mail; unfortunately, it had been long
gone from my mailbox, so I'd picked it from archives and completely missed
the mangled address).
^ permalink raw reply
* linux-next: manual merge of the block tree with the vfs tree
From: Stephen Rothwell @ 2016-12-12 1:31 UTC (permalink / raw)
To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/logfs/dev_bdev.c
between commit:
6b4fbde3b979 ("logfs: remove from tree")
from the vfs tree and commitis:
3a83f4677539 ("block: bio: pass bvec table to bio_init()")
739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
05aea81b4bc9 ("fs: logfs: remove unnecesary check")
from the block tree.
I fixed it up (I removed the file) 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.
Al: that vfs tree commit has a bad email address for Christoph in it :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the drm tree with the jc_docs tree
From: Stephen Rothwell @ 2016-12-12 0:57 UTC (permalink / raw)
To: Dave Airlie, Jonathan Corbet
Cc: linux-next, linux-kernel, Daniel Vetter, SeongJae Park
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
Documentation/driver-api/infrastructure.rst
between commits:
3080b056b3d4 ("docs/driver-api: Apply changed source file names")
868c97a846a7 ("dma-buf: Extract dma-buf.rst")
from the jc_docs tree and commit:
8a5846bf5d47 ("doc/dma-buf: Fix up include directives")
from the drm tree.
I fixed it up (the text modified by the latter was also modified by
commit 3080b056b3d4, then 868c97a846a7 moved it all to another file) 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: build failure after merge of the hid tree
From: Stephen Rothwell @ 2016-12-11 23:59 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, João Paulo Rechi Vita,
David Arcari
Hi Jiri,
After merging the hid tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/hid/i2c-hid/i2c-hid.c: In function 'i2c_hid_start':
drivers/hid/i2c-hid/i2c-hid.c:773:19: error: 'struct i2c_hid' has no member named 'irq'
disable_irq(ihid->irq);
^
drivers/hid/i2c-hid/i2c-hid.c:777:18: error: 'struct i2c_hid' has no member named 'irq'
enable_irq(ihid->irq);
^
Caused by commit
de3c99488609 ("HID: i2c-hid: Disable IRQ before freeing buffers")
interacting with commit
ba18a9314a94 ("Revert "HID: i2c-hid: Add support for ACPI GPIO interrupts"")
from earlier in the same tree!
I have used the hid tree from next-20161209 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the vfs-miklos tree with the vfs tree
From: Stephen Rothwell @ 2016-12-11 23:38 UTC (permalink / raw)
To: Miklos Szeredi, Al Viro
Cc: linux-next, linux-kernel, Christoph Hellwig, Darrick J. Wong
Hi Miklos,
Today's linux-next merge of the vfs-miklos tree got a conflict in:
fs/read_write.c
between commit:
a76b5b04375f ("fs: try to clone files first in vfs_copy_file_range")
from the vfs tree and commit:
b2368d2bb4a5 ("vfs: check file types in vfs_copy_file_range()")
from the vfs-miklos tree.
I fixed it up (I used the vfs tree version) 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.
Darrick, commit a76b5b04375f has no Signed-off-by from you as committer :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the vfs tree with the xfs tree
From: Stephen Rothwell @ 2016-12-11 23:19 UTC (permalink / raw)
To: Al Viro, David Chinner, linux-xfs
Cc: linux-next, linux-kernel, Darrick J. Wong
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/xfs/xfs_reflink.c
between commit:
fba3e594ef0a ("xfs: always succeed when deduping zero bytes")
from the xfs tree and commit:
876bec6f9bbf ("vfs: refactor clone/dedupe_file_range common functions")
from the vfs tree.
I fixed it up (the latter removed some code updated by the former and
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 fs/xfs/xfs_reflink.c
index 88fd03c66e99,95d6828967f0..000000000000
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@@ -1251,32 -1194,16 +1143,14 @@@ xfs_reflink_remap_range
return -EIO;
/* Lock both files against IO */
- if (same_inode) {
- xfs_ilock(src, XFS_IOLOCK_EXCL);
+ lock_two_nondirectories(inode_in, inode_out);
+ if (same_inode)
xfs_ilock(src, XFS_MMAPLOCK_EXCL);
- } else {
- xfs_lock_two_inodes(src, dest, XFS_IOLOCK_EXCL);
+ else
xfs_lock_two_inodes(src, dest, XFS_MMAPLOCK_EXCL);
- }
- /* Don't touch certain kinds of inodes */
- ret = -EPERM;
- if (IS_IMMUTABLE(inode_out))
- goto out_unlock;
-
- ret = -ETXTBSY;
- if (IS_SWAPFILE(inode_in) || IS_SWAPFILE(inode_out))
- goto out_unlock;
-
-
- /* Don't reflink dirs, pipes, sockets... */
- ret = -EISDIR;
- if (S_ISDIR(inode_in->i_mode) || S_ISDIR(inode_out->i_mode))
- goto out_unlock;
+ /* Check file eligibility and prepare for block sharing. */
ret = -EINVAL;
- if (S_ISFIFO(inode_in->i_mode) || S_ISFIFO(inode_out->i_mode))
- goto out_unlock;
- if (!S_ISREG(inode_in->i_mode) || !S_ISREG(inode_out->i_mode))
- goto out_unlock;
-
/* Don't reflink realtime inodes */
if (XFS_IS_REALTIME_INODE(src) || XFS_IS_REALTIME_INODE(dest))
goto out_unlock;
^ permalink raw reply
* linux-next: manual merge of the vfs tree with the overlayfs tree
From: Stephen Rothwell @ 2016-12-11 23:13 UTC (permalink / raw)
To: Al Viro, Miklos Szeredi; +Cc: linux-next, linux-kernel
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/overlayfs/copy_up.c
between commit:
4a756233184d ("Revert "ovl: Warn on copy up if a process has a R/O fd open to the lower file"")
from the overlayfs tree and commit:
450630975da9 ("don't open-code file_inode()")
from the vfs tree.
I fixed it up (the former removed the code updated by the latter) 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 vfs tree with the overlayfs tree
From: Stephen Rothwell @ 2016-12-11 23:08 UTC (permalink / raw)
To: Al Viro, Miklos Szeredi; +Cc: linux-next, linux-kernel
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/overlayfs/dir.c
between commits:
659f95a46dd0 ("ovl: add ovl_dentry_is_whiteout()")
ee2e4303d554 ("ovl: opaque cleanup")
f7cd4e7b2743 ("ovl: clean up kstat usage")
from the overlayfs tree and commit:
718324db4435 ("overlayfs: stop abusing kstat")
from the vfs tree.
It looks like commits f7cd4e7b2743 and 718324db4435 are essentially the
smae change (with some white space differences).
I fixed it up (I just took bits from each of teh above) 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.
Miklos, that overlayfs tree commit f7cd4e7b2743 has no Signed-off-by
from Al as its Author :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build warning after merge of the clk tree
From: Stephen Rothwell @ 2016-12-11 21:39 UTC (permalink / raw)
To: Mike Turquette, Stephen Boyd; +Cc: linux-next, linux-kernel, Boris Brezillon
Hi all,
After merging the clk tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/clk/bcm/clk-bcm2835.c: In function 'bcm2835_clock_determine_rate':
drivers/clk/bcm/clk-bcm2835.c:1069:18: warning: 'best_rate' may be used uninitialized in this function [-Wmaybe-uninitialized]
*prate = curdiv * best_rate;
^
drivers/clk/bcm/clk-bcm2835.c:1032:16: note: 'best_rate' was declared here
unsigned long best_rate;
^
Introduced by commit
155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: no v4.11 code yet
From: Stephen Rothwell @ 2016-12-11 20:54 UTC (permalink / raw)
To: LKML, linux-next
Hi all,
Please do not add any v4.11 code to your linux-next included branches
until after v4.10-rc1 has been released.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* (unknown),
From: cl_luzcc @ 2016-12-11 18:20 UTC (permalink / raw)
To: linux-next
[-- Attachment #1: EMAIL_3090637_linux-next.zip --]
[-- Type: application/zip, Size: 3420 bytes --]
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Emese Revfy @ 2016-12-10 16:45 UTC (permalink / raw)
To: Kees Cook
Cc: Arnd Bergmann, Stephen Rothwell, Randy Dunlap, Olof Johansson,
Mark Brown, info, Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team
In-Reply-To: <CAGXu5jJpBiffFhdQ+sjwWeeWOnpEkz4JQyH8VwmVCWP3TzXmLQ@mail.gmail.com>
On Fri, 9 Dec 2016 11:12:18 -0800
Kees Cook <keescook@google.com> wrote:
> On Fri, Dec 9, 2016 at 2:40 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
> >
> >> If you have a moment, applying 215e2aa6c024[1] and reverting
> >> a519167e753e for an allyesconfig/allmodconfig build should let you
> >> know if things are working correctly with headers installed. If anyone
> >> sees any problems, please let me know and I can queue up fixes.
> >
> > Using gcc-4.9.3 or gcc-5.3.1 for an ARM allmodconfig build, I get tons of
> > errors such as this one:
> >
> > /git/arm-soc/init/initramfs.c: In function 'error':
> > /git/arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
> > }
> > ^
> > (insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
> > (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
> > (const_int -30 [0xffffffffffffffe2]))) -1
> > (nil))
> > *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
> > Event | Plugins
> > PLUGIN_ATTRIBUTES | latent_entropy_plugin
> > PLUGIN_START_UNIT | latent_entropy_plugin
> > /git/arm-soc/init/initramfs.c:50:1: internal compiler error: in extract_insn, at recog.c:2202
> > /git/arm-soc/arch/arm/vfp/vfpmodule.c: In function 'vfp_init':
> > /git/arm-soc/arch/arm/vfp/vfpmodule.c:824:1: error: unrecognizable insn:
> > }
> > ^
> > (insn 138 137 139 17 (set (reg:SI 165 [ local_entropy.93 ])
> > (rotatert:SI (reg:SI 150 [ local_entropy.93 ])
> > (const_int -9 [0xfffffffffffffff7]))) -1
> > (nil))
> > *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
>
> Well that's exciting! :P
Hi,
You can find the fix here:
https://github.com/ephox-gcc-plugins/latent_entropy/commit/c91275a1bfcebbcfc0ca1af03396e06039f04db8
--
Emese
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Pablo Neira Ayuso @ 2016-12-10 12:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paul Gortmaker, netfilter-devel, David Miller, netdev,
linux-next@vger.kernel.org
In-Reply-To: <1481296926.4930.171.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Dec 09, 2016 at 07:22:06AM -0800, Eric Dumazet wrote:
> On Fri, 2016-12-09 at 06:24 -0800, Eric Dumazet wrote:
>
> > It looks that you want a seqcount, even on 64bit arches,
> > so that CPU 2 can restart its loop, and more importantly you need
> > to not accumulate the values you read, because they might be old/invalid.
>
> Untested patch to give general idea. I can polish it a bit later today.
I'm preparing a patch now, so you can review it.
Eric, thanks a lot for reviewing and proposing a working approach!
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: kugan @ 2016-12-09 21:08 UTC (permalink / raw)
To: Arnd Bergmann, Kees Cook
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team, Emese Revfy, maxim.kuvyrkov, Kugan Vivekanandarajah
In-Reply-To: <4284516.VtSFlm1aM8@wuerfel>
On 10/12/16 07:35, Arnd Bergmann wrote:
> On Friday, December 9, 2016 11:13:20 AM CET Kees Cook wrote:
>> On Fri, Dec 9, 2016 at 3:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
>>>> If you have a moment, applying 215e2aa6c024[1] and reverting
>>>> a519167e753e for an allyesconfig/allmodconfig build should let you
>>>> know if things are working correctly with headers installed. If anyone
>>>> sees any problems, please let me know and I can queue up fixes.
>>>>
>>> This is what I got on x86-64 with a gcc-7.0.0 snapshot:
>>>
>>> In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:42:0,
>>> from <stdin>:1:
>>> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/emit-rtl.h:371:41: error: use of enum ‘memmodel’ without previous declaration
>>> extern bool need_atomic_barrier_p (enum memmodel, bool);
>>> ^
>>> In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:94:0,
>>> from <stdin>:1:
>>> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:70:40: error: use of enum ‘value_range_type’ without previous declaration
>>> extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
>>> ^
>>> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:73:13: error: use of enum ‘value_range_type’ without previous declaration
>>> extern enum value_range_type get_range_info (const_tree, wide_int *,
>>> ^
>>> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:98:55: error: use of enum ‘value_range_type’ without previous declaration
>>> extern void duplicate_ssa_name_range_info (tree, enum value_range_type,
>>> ^
>>> Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
>>> scripts/Makefile.gcc-plugins:51: recipe for target 'gcc-plugins-check' failed
>>>
>>> I manually fixed up the gcc header files to include the ones with the
>>> definition for now, to address those, but I don't know if that change is
>>> correct.
>>
>> What was needed?
>
> I added '#include "memmodel.h"' and '#include "tree-vrp.h"', respectively, to
> the headers that failed to get compiled.
>
> This might be the correct solution, or the headers might not be meant to
> be used standalone and instead require being included in the right order.
>
> Gcc commit svn+ssh://gcc.gnu.org/svn/gcc/trunk@239638 moved
> value_range_type from tree-ssanames.h to tree-vrp.h, I've added
> Kugan to Cc, maybe he can clarify what that means for plugins.
Looks to me that in gcc-common.h tree-vrp.h should be included before
tree-ssanames.h as it is done in gcc now.
Thanks,
Kugan
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Arnd Bergmann @ 2016-12-09 20:35 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team, Emese Revfy, maxim.kuvyrkov, Kugan Vivekanandarajah
In-Reply-To: <CAGXu5jKtoN+uUa5zCmHR0=s8907kS3x30xMNc+s-On0_nyGiHg@mail.gmail.com>
On Friday, December 9, 2016 11:13:20 AM CET Kees Cook wrote:
> On Fri, Dec 9, 2016 at 3:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
> >> If you have a moment, applying 215e2aa6c024[1] and reverting
> >> a519167e753e for an allyesconfig/allmodconfig build should let you
> >> know if things are working correctly with headers installed. If anyone
> >> sees any problems, please let me know and I can queue up fixes.
> >>
> > This is what I got on x86-64 with a gcc-7.0.0 snapshot:
> >
> > In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:42:0,
> > from <stdin>:1:
> > /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/emit-rtl.h:371:41: error: use of enum ‘memmodel’ without previous declaration
> > extern bool need_atomic_barrier_p (enum memmodel, bool);
> > ^
> > In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:94:0,
> > from <stdin>:1:
> > /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:70:40: error: use of enum ‘value_range_type’ without previous declaration
> > extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
> > ^
> > /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:73:13: error: use of enum ‘value_range_type’ without previous declaration
> > extern enum value_range_type get_range_info (const_tree, wide_int *,
> > ^
> > /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:98:55: error: use of enum ‘value_range_type’ without previous declaration
> > extern void duplicate_ssa_name_range_info (tree, enum value_range_type,
> > ^
> > Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
> > scripts/Makefile.gcc-plugins:51: recipe for target 'gcc-plugins-check' failed
> >
> > I manually fixed up the gcc header files to include the ones with the
> > definition for now, to address those, but I don't know if that change is
> > correct.
>
> What was needed?
I added '#include "memmodel.h"' and '#include "tree-vrp.h"', respectively, to
the headers that failed to get compiled.
This might be the correct solution, or the headers might not be meant to
be used standalone and instead require being included in the right order.
Gcc commit svn+ssh://gcc.gnu.org/svn/gcc/trunk@239638 moved
value_range_type from tree-ssanames.h to tree-vrp.h, I've added
Kugan to Cc, maybe he can clarify what that means for plugins.
Arnd
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Linus Torvalds @ 2016-12-09 19:40 UTC (permalink / raw)
To: Kees Cook
Cc: Arnd Bergmann, Stephen Rothwell, Randy Dunlap, Olof Johansson,
Mark Brown, info, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team, Emese Revfy
In-Reply-To: <CAGXu5jJpBiffFhdQ+sjwWeeWOnpEkz4JQyH8VwmVCWP3TzXmLQ@mail.gmail.com>
On Fri, Dec 9, 2016 at 11:12 AM, Kees Cook <keescook@google.com> wrote:
>
> I'm starting to wonder if we need to expose the compiler version to
> Kconfig so that "all*config" builds for earlier compiler will
> automatically leave things like plugins off. But I have no idea what
> the right approach for that might be.
We had some broken mock-up of a config option that did a "system()"
call to do some shell scripting for filling in config options (ie turn
a fail/pass into false/true boolean automatically with something like
config COMPILER_SUPPORTS_XYZ
bool
option shell="gcc -XYZ"
The idea is really solid: move a lot of the nasty ad-hoc runtime
testing in the Makefiles to the configuration stage. I would seriously
like to see this, so that we could replace the stupid
CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
with just nicer thing (ok, that's a bad example, but some of the other
cc-option cases are really pretty fundamental to kernel configuration,
and it really matters whether the compiler supports something or not).
The main problem was actually that we don't have good infrastructure
for passing in the compiler environment etc to kbuild.
I forgot who did that mock-up (and what the exact syntax was), but it
was pretty simple.
Linus
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Kees Cook @ 2016-12-09 19:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team, Emese Revfy
In-Reply-To: <5572017.jUy2fe8FTb@wuerfel>
On Fri, Dec 9, 2016 at 3:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
>> Hi,
>>
>> I'd like to get the GCC plugins building under
>> allyesconfig/allmodconfig for -next soon (with the intention of
>> landing the change in v4.11). Specifically, I intend to revert
>> a519167e753e ("gcc-plugins: disable under COMPILE_TEST").
>>
>> Right now the plugins are only supported on x86, arm, and arm64,
>> though powerpc may happen in either v4.10 or v4.11 as well. This means
>> that the autobuilders for these architectures need to have the "gcc
>> plugin development" package installed which contains the GCC headers
>> needed for the plugins. For Debian/Ubuntu, this is gcc-$N-plugin-dev
>> (and for cross compilers: gcc-$N-plugin-dev-$arch-linux-$abi). For
>> Fedora, it is gcc-plugin-devel (though I'm not sure the naming for
>> cross compilers). Manual builds of compilers should already have these
>> headers installed.
>>
>> The "noisy" plugin, cyc_complexity, is just an example, and I have
>> disabled it (which is pending[1] for v4.10). The remaining ones
>> (sancov and latent_entropy) are what I'm hoping to see tested
>> tree-wide (with the expectation that more are coming down the road:
>> initify, randstruct, structleak, constify, ...)
>>
>> IIUC, the 0day builder already has the headers installed. I tried to
>> look through linux-next to find all the other folks that do
>> autobuilding on these architectures; apologies if I've missed anyone.
>>
>> If you have a moment, applying 215e2aa6c024[1] and reverting
>> a519167e753e for an allyesconfig/allmodconfig build should let you
>> know if things are working correctly with headers installed. If anyone
>> sees any problems, please let me know and I can queue up fixes.
>>
>> Thanks!
>>
>> -Kees
>>
>> [1] http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=for-next/gcc-plugins&id=215e2aa6c024d27cdbe88e2ea88cb59dcab588eb
>
> This is what I got on x86-64 with a gcc-7.0.0 snapshot:
>
> In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:42:0,
> from <stdin>:1:
> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/emit-rtl.h:371:41: error: use of enum ‘memmodel’ without previous declaration
> extern bool need_atomic_barrier_p (enum memmodel, bool);
> ^
> In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:94:0,
> from <stdin>:1:
> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:70:40: error: use of enum ‘value_range_type’ without previous declaration
> extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
> ^
> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:73:13: error: use of enum ‘value_range_type’ without previous declaration
> extern enum value_range_type get_range_info (const_tree, wide_int *,
> ^
> /home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:98:55: error: use of enum ‘value_range_type’ without previous declaration
> extern void duplicate_ssa_name_range_info (tree, enum value_range_type,
> ^
> Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
> scripts/Makefile.gcc-plugins:51: recipe for target 'gcc-plugins-check' failed
>
> I manually fixed up the gcc header files to include the ones with the
> definition for now, to address those, but I don't know if that change is
> correct.
What was needed?
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Kees Cook @ 2016-12-09 19:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org,
PaX Team, Emese Revfy
In-Reply-To: <2680957.ot0HfIkH6p@wuerfel>
On Fri, Dec 9, 2016 at 2:40 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
>
>> If you have a moment, applying 215e2aa6c024[1] and reverting
>> a519167e753e for an allyesconfig/allmodconfig build should let you
>> know if things are working correctly with headers installed. If anyone
>> sees any problems, please let me know and I can queue up fixes.
>
> Using gcc-4.9.3 or gcc-5.3.1 for an ARM allmodconfig build, I get tons of
> errors such as this one:
>
> /git/arm-soc/init/initramfs.c: In function 'error':
> /git/arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
> }
> ^
> (insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
> (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
> (const_int -30 [0xffffffffffffffe2]))) -1
> (nil))
> *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
> Event | Plugins
> PLUGIN_ATTRIBUTES | latent_entropy_plugin
> PLUGIN_START_UNIT | latent_entropy_plugin
> /git/arm-soc/init/initramfs.c:50:1: internal compiler error: in extract_insn, at recog.c:2202
> /git/arm-soc/arch/arm/vfp/vfpmodule.c: In function 'vfp_init':
> /git/arm-soc/arch/arm/vfp/vfpmodule.c:824:1: error: unrecognizable insn:
> }
> ^
> (insn 138 137 139 17 (set (reg:SI 165 [ local_entropy.93 ])
> (rotatert:SI (reg:SI 150 [ local_entropy.93 ])
> (const_int -9 [0xfffffffffffffff7]))) -1
> (nil))
> *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Well that's exciting! :P
>
> Using gcc-6.1.1 or gcc-7.0.0, everything works fine as far as I
> can tell. With some older Ubuntu binary toolchains, I get this one:
>
> In file included from <stdin>:1:0:
> /git/arm-soc/scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory
> compilation terminated.
> Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
>
> and I can't find the packages for the headers (I still get them for
> gcc-5, but not older versions). On very old toolchains (e.g. gcc-4.3),
> I get this one:
>
> Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, you should upgrade it to at least gcc 4.5
> scripts/Makefile.gcc-plugins:54: recipe for target 'gcc-plugins-check' failed
I'm starting to wonder if we need to expose the compiler version to
Kconfig so that "all*config" builds for earlier compiler will
automatically leave things like plugins off. But I have no idea what
the right approach for that might be.
I'm not a fan of silently disabling stuff (like is done, for example,
for KCOV). If you've selected a Kconfig that your compiler can't
build, it should fail to build, but that's different from the
allyesconfig etc, since that's about compile tests not a sane kernel
image.
Perhaps if COMPILE_TEST is enabled, and there is something unsupported
by the compiler, only then would it warn and continue, instead of
killing build?
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Eric Dumazet @ 2016-12-09 15:22 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Paul Gortmaker, netfilter-devel, David Miller, netdev,
linux-next@vger.kernel.org
In-Reply-To: <1481293492.4930.168.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, 2016-12-09 at 06:24 -0800, Eric Dumazet wrote:
> It looks that you want a seqcount, even on 64bit arches,
> so that CPU 2 can restart its loop, and more importantly you need
> to not accumulate the values you read, because they might be old/invalid.
Untested patch to give general idea. I can polish it a bit later today.
net/netfilter/nft_counter.c | 59 +++++++++++++---------------------
1 file changed, 23 insertions(+), 36 deletions(-)
diff --git a/net/netfilter/nft_counter.c b/net/netfilter/nft_counter.c
index f6a02c5071c2aeafca7635da3282a809aa04d6ab..57ed95b024473a2aa76298fe5bb5013bf709801b 100644
--- a/net/netfilter/nft_counter.c
+++ b/net/netfilter/nft_counter.c
@@ -31,18 +31,25 @@ struct nft_counter_percpu_priv {
struct nft_counter_percpu __percpu *counter;
};
+static DEFINE_PER_CPU(seqcount_t, nft_counter_seq);
+
static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
{
struct nft_counter_percpu *this_cpu;
+ seqcount_t *myseq;
local_bh_disable();
this_cpu = this_cpu_ptr(priv->counter);
- u64_stats_update_begin(&this_cpu->syncp);
+ myseq = this_cpu_ptr(&nft_counter_seq);
+
+ write_seqcount_begin(myseq);
+
this_cpu->counter.bytes += pkt->skb->len;
this_cpu->counter.packets++;
- u64_stats_update_end(&this_cpu->syncp);
+
+ write_seqcount_end(myseq);
local_bh_enable();
}
@@ -110,52 +117,30 @@ static void nft_counter_fetch(struct nft_counter_percpu __percpu *counter,
memset(total, 0, sizeof(*total));
for_each_possible_cpu(cpu) {
+ seqcount_t *seqp = per_cpu_ptr(&nft_counter_seq, cpu);
+
cpu_stats = per_cpu_ptr(counter, cpu);
do {
- seq = u64_stats_fetch_begin_irq(&cpu_stats->syncp);
+ seq = read_seqcount_begin(seqp);
bytes = cpu_stats->counter.bytes;
packets = cpu_stats->counter.packets;
- } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, seq));
+ } while (read_seqcount_retry(seqp, seq));
total->packets += packets;
total->bytes += bytes;
}
}
-static u64 __nft_counter_reset(u64 *counter)
-{
- u64 ret, old;
-
- do {
- old = *counter;
- ret = cmpxchg64(counter, old, 0);
- } while (ret != old);
-
- return ret;
-}
-
static void nft_counter_reset(struct nft_counter_percpu __percpu *counter,
struct nft_counter *total)
{
struct nft_counter_percpu *cpu_stats;
- u64 bytes, packets;
- unsigned int seq;
- int cpu;
- memset(total, 0, sizeof(*total));
- for_each_possible_cpu(cpu) {
- bytes = packets = 0;
-
- cpu_stats = per_cpu_ptr(counter, cpu);
- do {
- seq = u64_stats_fetch_begin_irq(&cpu_stats->syncp);
- packets += __nft_counter_reset(&cpu_stats->counter.packets);
- bytes += __nft_counter_reset(&cpu_stats->counter.bytes);
- } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, seq));
-
- total->packets += packets;
- total->bytes += bytes;
- }
+ local_bh_disable();
+ cpu_stats = this_cpu_ptr(counter);
+ cpu_stats->counter.packets -= total->packets;
+ cpu_stats->counter.bytes -= total->bytes;
+ local_bh_enable();
}
static int nft_counter_do_dump(struct sk_buff *skb,
@@ -164,10 +149,9 @@ static int nft_counter_do_dump(struct sk_buff *skb,
{
struct nft_counter total;
+ nft_counter_fetch(priv->counter, &total);
if (reset)
nft_counter_reset(priv->counter, &total);
- else
- nft_counter_fetch(priv->counter, &total);
if (nla_put_be64(skb, NFTA_COUNTER_BYTES, cpu_to_be64(total.bytes),
NFTA_COUNTER_PAD) ||
@@ -285,7 +269,10 @@ static struct nft_expr_type nft_counter_type __read_mostly = {
static int __init nft_counter_module_init(void)
{
- int err;
+ int err, cpu;
+
+ for_each_possible_cpu(cpu)
+ seqcount_init(per_cpu_ptr(&nft_counter_seq, cpu));
err = nft_register_obj(&nft_counter_obj);
if (err < 0)
^ permalink raw reply related
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Eric Dumazet @ 2016-12-09 14:24 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Paul Gortmaker, netfilter-devel, David Miller, netdev,
linux-next@vger.kernel.org
In-Reply-To: <20161209102432.GA986@salvia>
On Fri, 2016-12-09 at 11:24 +0100, Pablo Neira Ayuso wrote:
> Hi Paul,
Hi Pablo
Given that bytes/packets counters are modified without cmpxchg64() :
static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
{
struct nft_counter_percpu *this_cpu;
local_bh_disable();
this_cpu = this_cpu_ptr(priv->counter);
u64_stats_update_begin(&this_cpu->syncp);
this_cpu->counter.bytes += pkt->skb->len;
this_cpu->counter.packets++;
u64_stats_update_end(&this_cpu->syncp);
local_bh_enable();
}
It means that the cmpxchg64() used to clear the stats is not good enough.
It does not help to make sure stats are properly cleared.
On 64 bit, the ->syncp is not there, so the nft_counter_reset() might
not see that a bytes or packets counter was modified by another cpu.
CPU 1 CPU 2
LOAD PTR->BYTES into REG_A old = *counter;
REG_A += skb->len;
cmpxchg64(counter, old, 0);
PTR->BYTES = REG_A
It looks that you want a seqcount, even on 64bit arches,
so that CPU 2 can restart its loop, and more importantly you need
to not accumulate the values you read, because they might be old/invalid.
Another way would be to not use cmpxchg64() at all.
Way to expensive in fast path !
The percpu value would never be modified by an other cpu than the owner.
You need a per cpu seqcount, no need to add a syncp per nft percpu counter.
static DEFINE_PERCPU(seqcount_t, nft_pcpu_seq);
static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
{
struct nft_counter_percpu *this_cpu;
seqcount_t *myseq;
local_bh_disable();
this_cpu = this_cpu_ptr(priv->counter);
myseq = this_cpu_ptr(&nft_pcpu_seq);
write_seqcount_begin(myseq);
this_cpu->counter.bytes += pkt->skb->len;
this_cpu->counter.packets++;
write_seqcount_end(myseq);
local_bh_enable();
}
Thanks !
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Arnd Bergmann @ 2016-12-09 11:33 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org
In-Reply-To: <CAGXu5jLEg_4oOyT-rB8QaaYos854xp39_hNf7haNp=8frcPS0Q@mail.gmail.com>
On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
> Hi,
>
> I'd like to get the GCC plugins building under
> allyesconfig/allmodconfig for -next soon (with the intention of
> landing the change in v4.11). Specifically, I intend to revert
> a519167e753e ("gcc-plugins: disable under COMPILE_TEST").
>
> Right now the plugins are only supported on x86, arm, and arm64,
> though powerpc may happen in either v4.10 or v4.11 as well. This means
> that the autobuilders for these architectures need to have the "gcc
> plugin development" package installed which contains the GCC headers
> needed for the plugins. For Debian/Ubuntu, this is gcc-$N-plugin-dev
> (and for cross compilers: gcc-$N-plugin-dev-$arch-linux-$abi). For
> Fedora, it is gcc-plugin-devel (though I'm not sure the naming for
> cross compilers). Manual builds of compilers should already have these
> headers installed.
>
> The "noisy" plugin, cyc_complexity, is just an example, and I have
> disabled it (which is pending[1] for v4.10). The remaining ones
> (sancov and latent_entropy) are what I'm hoping to see tested
> tree-wide (with the expectation that more are coming down the road:
> initify, randstruct, structleak, constify, ...)
>
> IIUC, the 0day builder already has the headers installed. I tried to
> look through linux-next to find all the other folks that do
> autobuilding on these architectures; apologies if I've missed anyone.
>
> If you have a moment, applying 215e2aa6c024[1] and reverting
> a519167e753e for an allyesconfig/allmodconfig build should let you
> know if things are working correctly with headers installed. If anyone
> sees any problems, please let me know and I can queue up fixes.
>
> Thanks!
>
> -Kees
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=for-next/gcc-plugins&id=215e2aa6c024d27cdbe88e2ea88cb59dcab588eb
This is what I got on x86-64 with a gcc-7.0.0 snapshot:
In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:42:0,
from <stdin>:1:
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/emit-rtl.h:371:41: error: use of enum ‘memmodel’ without previous declaration
extern bool need_atomic_barrier_p (enum memmodel, bool);
^
In file included from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:94:0,
from <stdin>:1:
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:70:40: error: use of enum ‘value_range_type’ without previous declaration
extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
^
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:73:13: error: use of enum ‘value_range_type’ without previous declaration
extern enum value_range_type get_range_info (const_tree, wide_int *,
^
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/7.0.0/plugin/include/tree-ssanames.h:98:55: error: use of enum ‘value_range_type’ without previous declaration
extern void duplicate_ssa_name_range_info (tree, enum value_range_type,
^
Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
scripts/Makefile.gcc-plugins:51: recipe for target 'gcc-plugins-check' failed
I manually fixed up the gcc header files to include the ones with the
definition for now, to address those, but I don't know if that change is
correct.
Arnd
^ permalink raw reply
* Re: enabling COMPILE_TEST support for GCC plugins in v4.11
From: Arnd Bergmann @ 2016-12-09 10:40 UTC (permalink / raw)
To: Kees Cook
Cc: Stephen Rothwell, Randy Dunlap, Olof Johansson, Mark Brown, info,
Linus Torvalds, Andrew Morton, Will Deacon,
Russell King - ARM Linux, LKML, Linux-Next, Fengguang Wu,
Andrew Donnellan, Michael Ellerman, Laura Abbott, x86@kernel.org
In-Reply-To: <CAGXu5jLEg_4oOyT-rB8QaaYos854xp39_hNf7haNp=8frcPS0Q@mail.gmail.com>
On Thursday, December 8, 2016 11:00:42 AM CET Kees Cook wrote:
> If you have a moment, applying 215e2aa6c024[1] and reverting
> a519167e753e for an allyesconfig/allmodconfig build should let you
> know if things are working correctly with headers installed. If anyone
> sees any problems, please let me know and I can queue up fixes.
Using gcc-4.9.3 or gcc-5.3.1 for an ARM allmodconfig build, I get tons of
errors such as this one:
/git/arm-soc/init/initramfs.c: In function 'error':
/git/arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
}
^
(insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
(rotatert:SI (reg:SI 116 [ local_entropy.243 ])
(const_int -30 [0xffffffffffffffe2]))) -1
(nil))
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event | Plugins
PLUGIN_ATTRIBUTES | latent_entropy_plugin
PLUGIN_START_UNIT | latent_entropy_plugin
/git/arm-soc/init/initramfs.c:50:1: internal compiler error: in extract_insn, at recog.c:2202
/git/arm-soc/arch/arm/vfp/vfpmodule.c: In function 'vfp_init':
/git/arm-soc/arch/arm/vfp/vfpmodule.c:824:1: error: unrecognizable insn:
}
^
(insn 138 137 139 17 (set (reg:SI 165 [ local_entropy.93 ])
(rotatert:SI (reg:SI 150 [ local_entropy.93 ])
(const_int -9 [0xfffffffffffffff7]))) -1
(nil))
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Using gcc-6.1.1 or gcc-7.0.0, everything works fine as far as I
can tell. With some older Ubuntu binary toolchains, I get this one:
In file included from <stdin>:1:0:
/git/arm-soc/scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory
compilation terminated.
Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
and I can't find the packages for the headers (I still get them for
gcc-5, but not older versions). On very old toolchains (e.g. gcc-4.3),
I get this one:
Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, you should upgrade it to at least gcc 4.5
scripts/Makefile.gcc-plugins:54: recipe for target 'gcc-plugins-check' failed
Arnd
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Pablo Neira Ayuso @ 2016-12-09 10:24 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netfilter-devel, David Miller, netdev, linux-next@vger.kernel.org
In-Reply-To: <CAP=VYLp-ZBFjR1W9=V_vyPYAi1=Yub3ugq6D8hkoLigcPaaxFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]
Hi Paul,
On Thu, Dec 08, 2016 at 07:40:14PM -0500, Paul Gortmaker wrote:
> On Wed, Dec 7, 2016 at 4:52 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> > dump-and-reset of the stateful object. This also comes with add support
> > for atomic dump and reset for counter and quota objects.
>
> This triggered a new build failure in linux-next on parisc-32, which a
> hands-off bisect
> run lists as resulting from this:
>
> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
> 43da04a593d8b2626f1cf4b56efe9402f6b53652 is the first bad commit
> commit 43da04a593d8b2626f1cf4b56efe9402f6b53652
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon Nov 28 00:05:44 2016 +0100
>
> netfilter: nf_tables: atomic dump and reset for stateful objects
>
> This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> dump-and-reset of the stateful object. This also comes with add support
> for atomic dump and reset for counter and quota objects.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> :040000 040000 6cd4554f69247e5c837db52342f26888beda1623
> 5908aca93c89e7922336546c3753bfcf2aceefba M include
> :040000 040000 f25d5831eb30972436bd198c5bb237a0cb0b4856
> 4ee5751c8de02bb5a8dcaadb2a2df7986d90f8e9 M net
> bisect run success
>
> Guessing this is more an issue with parisc than it is with netfilter, but I
> figured I'd mention it anyway.
I'm planning to submit this patch to parisc, I'm attaching it to this
email.
[-- Attachment #2: 0001-parisc-export-symbol-__cmpxchg_u64.patch --]
[-- Type: text/x-diff, Size: 1313 bytes --]
>From c9d320ac0be2a32a7b2bfad398be549865088ecf Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 8 Dec 2016 22:55:33 +0100
Subject: [PATCH] parisc: export symbol __cmpxchg_u64()
kbuild test robot reports:
>> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
Commit 43da04a593d8 ("netfilter: nf_tables: atomic dump and reset for
stateful objects") introduces the first client of cmpxchg64() from
modules.
Patch 54b668009076 ("parisc: Add native high-resolution sched_clock()
implementation") removed __cmpxchg_u64() dependency on CONFIG_64BIT.
So, let's fix this problem by exporting this symbol unconditionally.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
arch/parisc/kernel/parisc_ksyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index 3cad8aadc69e..cfa704548cf3 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -40,8 +40,8 @@ EXPORT_SYMBOL(__atomic_hash);
#endif
#ifdef CONFIG_64BIT
EXPORT_SYMBOL(__xchg64);
-EXPORT_SYMBOL(__cmpxchg_u64);
#endif
+EXPORT_SYMBOL(__cmpxchg_u64);
#include <asm/uaccess.h>
EXPORT_SYMBOL(lclear_user);
--
2.1.4
^ permalink raw reply related
* next-20161209 build: 0 failures 2 warnings (next-20161209)
From: Build bot for Mark Brown @ 2016-12-09 9:15 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20161209
Git describe: next-20161209
Commit: 4a71e4389b Add linux-next specific files for 20161209
Build Time: 98 min 43 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
2 ../include/uapi/linux/byteorder/big_endian.h:34:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
1 ../drivers/net/ethernet/apm/xgene/xgene_enet_cle.c:836:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/uapi/linux/byteorder/big_endian.h:34:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/net/ethernet/apm/xgene/xgene_enet_cle.c:836:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../include/uapi/linux/byteorder/big_endian.h:34:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
^ 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