* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Arnd Bergmann @ 2016-11-08 22:14 UTC (permalink / raw)
To: kernel-build-reports
Cc: Olof's autobuilder, olof, stable, Greg KH, Eric W. Biederman
In-Reply-To: <5822086c.4666420a.e9479.80e9@mx.google.com>
On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> Here are the build results from automated periodic testing.
>
> The tree being built was stable-rc, found at:
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>
> Topmost commit:
>
> f821e08 Linux 4.4.31-rc1
>
> Build logs (stderr only) can be found at the following link (experimental):
>
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
These seem to be largely caused by building with gcc-6. It's probably
a good idea to keep supporting that configuration though and
backport the fixes. Here are the upstream commit IDs I've found.
> -------------------------------------------------------------------------------
>
> Failed defconfigs:
> powerpc.pasemi_defconfig
>
> -------------------------------------------------------------------------------
>
> Errors:
>
> powerpc.pasemi_defconfig:
> /work/build/batch/arch/powerpc/kernel/ptrace.c:378:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]
> /work/build/batch/arch/powerpc/kernel/ptrace.c:406:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]
1e407ee3b21f ("powerpc/ptrace: Fix out of bounds array access warning")
> Warnings:
>
> 1 drivers/block/floppy.c:1777:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:1779:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:4479:45: warning: self-comparison always evaluates to true [-Wtautological-compare]
> 1 drivers/block/floppy.c:4487:45: warning: self-comparison always evaluates to true [-Wtautological-compare]
dd665be0e243 ("ARM: 8584/1: floppy: avoid gcc-6 warning")
> 1 drivers/of/of_reserved_mem.c:131:180: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:182: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:364: warning: comparison of distinct pointer types lacks a cast
> 1 drivers/of/of_reserved_mem.c:131:368: warning: comparison of distinct pointer types lacks a cast
aaaab56dba9a ("of: silence warnings due to max() usage")
> 1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of
devpts an independent filesystem."), which unfortunately is not a candidate for stable
> 1 kernel/sched/core.c:2941:26: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> 1 kernel/sched/core.c:2943:27: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
A number of patches went in for this one, the last one was
ef6000b4c670 ("Disable the __builtin_return_address() warning globally after all")
> 1 mm/cma.c:186:131: warning: comparison of distinct pointer types lacks a cast
> 1 mm/cma.c:269:193: warning: comparison of distinct pointer types lacks a cast
> 1 mm/cma.c:269:379: warning: comparison of distinct pointer types lacks a cast
badbda53e505 ("mm/cma: silence warnings due to max() usage")
> 1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
Apparently also fixed as a side-effect of a larger patch:
9847371a84b0 ("netfilter: Allow xt_owner in any user namespace")
This one might be appropriate for a stable backport, Eric Biederman
would know for sure.
> 4 drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: warning: self-comparison always evaluates to false [-Wtautological-compare]
55c4b906aa2a ("drm/exynos: fix error handling in exynos_drm_subdrv_open")
> 4 drivers/i2c/busses/i2c-imx.c:1007:10: warning: 'return' with a value, in function returning void
The same one showed up in linux-4.8.y-rc earlier today and is now gone, I assume
it was already fixed there.
> 9 kernel/cgroup.c:239:396: warning: array subscript is above array bounds [-Warray-bounds]
cfe02a8a973e ("cgroup: avoid false positive gcc-6 warning")
> 19 drivers/net/ethernet/smsc/smc91x.c:563:14: warning: self-comparison always evaluates to true [-Wtautological-compare]
e3ebd894f084 ("smc91x: avoid self-comparison warning")
> 1 include/uapi/linux/swab.h:14:33: warning: integer overflow in expression [-Woverflow]
> 5 kernel/audit.c:663:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 6 kernel/taskstats.c:289:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 4 drivers/connector/cn_proc.c:349:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
> 2 fs/xfs/xfs_ioctl.c:1166:22: warning: self-comparison always evaluates to true [-Wtautological-compare]
No idea.
Arnd
^ permalink raw reply
* Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support
From: Luis R. Rodriguez @ 2016-11-08 22:14 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Luis R. Rodriguez, linux-pm, linux-kernel, iommu,
linux-samsung-soc, Joerg Roedel, Inki Dae, Kukjin Kim,
Krzysztof Kozłowski, Bartlomiej Zolnierkiewicz,
Rafael J. Wysocki, Mark Brown, Greg Kroah-Hartman, Tomeu Vizoso,
Lukas Wunner, Kevin Hilman, Tobias Jakobi, Laurent Pinchart,
Lars-Peter Clausen, Dmitry Torokhov, Grant Likely,
Mauro Carvalho Chehab
In-Reply-To: <87aeb58b-bda0-93c5-e51d-ab9be0b9d518@samsung.com>
On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote:
> Hi Luis
>
>
> On 2016-10-06 19:37, Luis R. Rodriguez wrote:
> > On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote:
> > > This patch uses recently introduced device links to track the runtime pm
> > > state of the master's device. This way each SYSMMU controller is runtime
> > > activated when its master's device is active
> > instead of?
>
> instead of keeping SYSMMU controller runtime active all the time.
I thought Rafael's work was for suspend/resume, not for runtime suspend.
Is it for both ? Because as far as I can tell this was painted to help
with suspend/resume ?
> > BTW what is the master device of a SYSMMU? I have no clue about these
> > IOMMU devices here.
>
> Here is a more detailed description of IOMMU hardware I wrote a few days ago
> for Ulf:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1231006.html
>
> In short: there is a SYSMMU controller and its master device - a device,
> which performs DMA operations. That SYSMMU sits in between system memory
> and the master device, so it performs mapping of DMA addresses to physical
> memory addresses on each DMA operation.
So you seek a run time power optimization ? Or a fix on suspend? Or both?
> > > and can save/restore its state instead of being enabled all the time.
> > I take it this means currently even if the master device is disabled
> > (whatever that is) all SYSMMU controllers are kept enabled, is that right?
> > The issue here is this wastes power? Or what is the issue?
>
> Yes, the issue here is the fact that SYSMMU is kept active all the time,
> what in turn prevent the power domain for turning off even if master device
> doesn't do anything and is already suspended. This directly (some clocks
> enabled) and in-directly (leakage current) causes power looses.
Thanks for the confirmation so really the biggest concern here was run time PM.
> > > This way SYSMMU controllers no
> > > longer prevents respective power domains to be turned off when master's
> > > device is not used.
> > So when the master device is idle we want to also remove power from the
> > controllers ? How much power does this save on a typical device in the
> > market BTW ?
>
> The main purpose of this patchset is to let power domains to be turned off,
> because with the current code all domains are all the time turned on,
> because
> SYSMMU controllers prevent them from turning them off.
I see.. I think the audio folks already addressed this with DAPM, but granted
this was for audio. Then I was also referred to the DRM / Audio component
framework, has this been looked into? v4l folks have v4l async stuff but
its not clear if that help with run time PM. I'm mentioning these given it'd be
silly to re-invent the wheel, additionally if we now have a generic solution
everyone can jump on board with there is quite a bit of work we can do to
dump a lot of old legacy crap.
> If you want I can measure the power consumption of the idle board with all
> domains enabled and disabled if you want to see the numbers. On the other
> board
> disabling most power domains in idle state (the clocks were already
> disabled)
> gave me about 20mA savings (at 3.7V), what is a significant value for the
> battery powered device.
Thanks, this means nothing to me, however it would be value-add to the commit log
as anyone reviewing this can understand what the goal / savings was for exactly.
> >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > ---
> > > drivers/iommu/exynos-iommu.c | 225 ++++++++++++++++++-------------------------
> > > 1 file changed, 94 insertions(+), 131 deletions(-)
> > I'm reviewing the device link patches now but since this is a demo of
> > use of that I'll note the changes here are pretty large and it makes
> > it terribly difficult for review. Is there any way this patch can be split
> > up in to logical atomic pieces that only do one task upon change ?
>
> I will try to split it a bit, but I cannot promise that much can be done
> to improve readability for someone not very familiar with the driver
> internals.
I've heard this before, I don't buy it but lets see!
Luis
^ permalink raw reply
* Re: [PATCH 1/3] kbuild: add -fno-PIE
From: Michal Marek @ 2016-11-08 22:14 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-kbuild, x86, Al Viro, Ben Hutchings,
Sven Joachim, Austin S. Hemmelgarn, Borislav Petkov
In-Reply-To: <20161104183940.30692-2-bigeasy@linutronix.de>
On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> Debian started to build the gcc with -fPIE by default so the kernel
> build ends before it starts properly with:
> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>
> Also add to KBUILD_AFLAGS due to:
>
> |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
> |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
>
> Tagging it stable so it is possible to compile recent stable kernels as
> well.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index a2650f9c6a25..d61145ebf498 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -622,6 +622,8 @@ include arch/$(SRCARCH)/Makefile
> KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
> KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
> +KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
> +KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
Bad compiler. No pie for you.
I applied this one to kbuild.git. How about 2/3 and 3/3. Will these be
merged via tip.git or shall I apply them as well?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support
From: Luis R. Rodriguez @ 2016-11-08 22:14 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Luis R. Rodriguez, linux-pm, linux-kernel, iommu,
linux-samsung-soc, Joerg Roedel, Inki Dae, Kukjin Kim,
Krzysztof Kozłowski, Bartlomiej Zolnierkiewicz,
Rafael J. Wysocki, Mark Brown, Greg Kroah-Hartman, Tomeu Vizoso,
Lukas Wunner, Kevin Hilman, Tobias Jakobi, Laurent Pinchart,
Lars-Peter Clausen
In-Reply-To: <87aeb58b-bda0-93c5-e51d-ab9be0b9d518@samsung.com>
On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote:
> Hi Luis
>
>
> On 2016-10-06 19:37, Luis R. Rodriguez wrote:
> > On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote:
> > > This patch uses recently introduced device links to track the runtime pm
> > > state of the master's device. This way each SYSMMU controller is runtime
> > > activated when its master's device is active
> > instead of?
>
> instead of keeping SYSMMU controller runtime active all the time.
I thought Rafael's work was for suspend/resume, not for runtime suspend.
Is it for both ? Because as far as I can tell this was painted to help
with suspend/resume ?
> > BTW what is the master device of a SYSMMU? I have no clue about these
> > IOMMU devices here.
>
> Here is a more detailed description of IOMMU hardware I wrote a few days ago
> for Ulf:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1231006.html
>
> In short: there is a SYSMMU controller and its master device - a device,
> which performs DMA operations. That SYSMMU sits in between system memory
> and the master device, so it performs mapping of DMA addresses to physical
> memory addresses on each DMA operation.
So you seek a run time power optimization ? Or a fix on suspend? Or both?
> > > and can save/restore its state instead of being enabled all the time.
> > I take it this means currently even if the master device is disabled
> > (whatever that is) all SYSMMU controllers are kept enabled, is that right?
> > The issue here is this wastes power? Or what is the issue?
>
> Yes, the issue here is the fact that SYSMMU is kept active all the time,
> what in turn prevent the power domain for turning off even if master device
> doesn't do anything and is already suspended. This directly (some clocks
> enabled) and in-directly (leakage current) causes power looses.
Thanks for the confirmation so really the biggest concern here was run time PM.
> > > This way SYSMMU controllers no
> > > longer prevents respective power domains to be turned off when master's
> > > device is not used.
> > So when the master device is idle we want to also remove power from the
> > controllers ? How much power does this save on a typical device in the
> > market BTW ?
>
> The main purpose of this patchset is to let power domains to be turned off,
> because with the current code all domains are all the time turned on,
> because
> SYSMMU controllers prevent them from turning them off.
I see.. I think the audio folks already addressed this with DAPM, but granted
this was for audio. Then I was also referred to the DRM / Audio component
framework, has this been looked into? v4l folks have v4l async stuff but
its not clear if that help with run time PM. I'm mentioning these given it'd be
silly to re-invent the wheel, additionally if we now have a generic solution
everyone can jump on board with there is quite a bit of work we can do to
dump a lot of old legacy crap.
> If you want I can measure the power consumption of the idle board with all
> domains enabled and disabled if you want to see the numbers. On the other
> board
> disabling most power domains in idle state (the clocks were already
> disabled)
> gave me about 20mA savings (at 3.7V), what is a significant value for the
> battery powered device.
Thanks, this means nothing to me, however it would be value-add to the commit log
as anyone reviewing this can understand what the goal / savings was for exactly.
> >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > ---
> > > drivers/iommu/exynos-iommu.c | 225 ++++++++++++++++++-------------------------
> > > 1 file changed, 94 insertions(+), 131 deletions(-)
> > I'm reviewing the device link patches now but since this is a demo of
> > use of that I'll note the changes here are pretty large and it makes
> > it terribly difficult for review. Is there any way this patch can be split
> > up in to logical atomic pieces that only do one task upon change ?
>
> I will try to split it a bit, but I cannot promise that much can be done
> to improve readability for someone not very familiar with the driver
> internals.
I've heard this before, I don't buy it but lets see!
Luis
^ permalink raw reply
* [PATCH 1/1] fanotify_mark.2: mention FAN_Q_OVERFLOW
From: Heinrich Schuchardt @ 2016-11-08 22:13 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, Heinrich Schuchardt
To receive overflow events it is necessary to set this bit
in fanotify_mark().
Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
---
man2/fanotify_mark.2 | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2
index 88aa17e..4933ecc 100644
--- a/man2/fanotify_mark.2
+++ b/man2/fanotify_mark.2
@@ -149,6 +149,13 @@ Create an event when a read-only file or directory is closed.
.B FAN_OPEN
Create an event when a file or directory is opened.
.TP
+.B FAN_Q_OVERFLOW
+Create an event when an overflow of the event queue occurs.
+The size of the event queue is limited to 16384 entries if
+.B FAN_UNLIMITED_QUEUE
+is not set in
+.BR fanotify_init (2).
+.TP
.B FAN_OPEN_PERM
Create an event when a permission to open a file or directory is requested.
An fanotify file descriptor created with
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v10 7/7] KVM: x86: virtualize cpuid faulting
From: David Matlack @ 2016-11-08 22:12 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, X86 ML, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Borislav Petkov,
Peter Zijlstra, Boris Ostrovsky, Len Brown, Rafael J. Wysocki,
Dmitry Safonov
In-Reply-To: <20161108183956.4521-8-khuey@kylehuey.com>
On Tue, Nov 8, 2016 at 10:39 AM, Kyle Huey <me@kylehuey.com> wrote:
> Hardware support for faulting on the cpuid instruction is not required to
> emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
> MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
> cpuid-induced VM exit checks the cpuid faulting state and the CPL.
> kvm_require_cpl is even kind enough to inject the GP fault for us.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Reviewed-by: David Matlack <dmatlack@google.com>
(v10)
^ permalink raw reply
* Re: [PATCH v10 7/7] KVM: x86: virtualize cpuid faulting
From: David Matlack @ 2016-11-08 22:12 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, X86 ML, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Borislav Petkov,
Peter Zijlstra, Boris Ostrovsky, Len Brown, Rafael J. Wysocki,
Dmitry Safonov, linux-kernel@vger.kernel.org,
user-mode-linux-devel, user-mode-linux-user, linux-fsdevel,
linux-kselftest, kvm list
In-Reply-To: <20161108183956.4521-8-khuey@kylehuey.com>
On Tue, Nov 8, 2016 at 10:39 AM, Kyle Huey <me@kylehuey.com> wrote:
> Hardware support for faulting on the cpuid instruction is not required to
> emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
> MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
> cpuid-induced VM exit checks the cpuid faulting state and the CPL.
> kvm_require_cpl is even kind enough to inject the GP fault for us.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
Reviewed-by: David Matlack <dmatlack@google.com>
(v10)
^ permalink raw reply
* Re: KASAN & the vmalloc area
From: Dmitry Vyukov @ 2016-11-08 22:09 UTC (permalink / raw)
To: Mark Rutland
Cc: Andy Lutomirski, Andrey Ryabinin, Laura Abbott, Ard Biesheuvel,
LKML, linux-arm-kernel, kasan-dev
In-Reply-To: <20161108190302.GH15297@leverpostej>
On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> I see a while back [1] there was a discussion of what to do about KASAN
> and vmapped stacks, but it doesn't look like that was solved, judging by
> the vmapped stacks pull [2] for v4.9.
>
> I wondered whether anyone had looked at that since?
>
> I have an additional reason to want to dynamically allocate the vmalloc
> area shadow: it turns out that KASAN currently interacts rather poorly
> with the arm64 ptdump code.
>
> When KASAN is selected, we allocate shadow for the whole vmalloc area,
> using common zero pte, pmd, pud tables. Walking over these in the ptdump
> code takes a *very* long time (I've seen up to 15 minutes with
> KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that
> long, too.
>
> If I don't allocate vmalloc shadow (and remove the apparently pointlesss
> shadow of the shadow area), and only allocate shadow for the image,
> fixmap, vmemmap and so on, that delay gets cut to a few seconds, which
> is tolerable for a debug configuration...
>
> ... however, things blow up when the kernel touches vmalloc'd memory for
> the first time, as we don't install shadow for that dynamically.
I've seen the same iteration slowness problem on x86 with
CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
it is enough to trigger rcu stall warning.
The zero pud and vmalloc-ed stacks looks like different problems.
To overcome the slowness we could map zero shadow for vmalloc area lazily.
However for vmalloc-ed stacks we need to map actual memory, because
stack instrumentation will read/write into the shadow. One downside
here is that vmalloc shadow can be as large as 1:1 (if we allocate 1
page in vmalloc area we need to allocate 1 page for shadow).
Re slowness: could we just skip the KASAN zero puds (the top level)
while walking? Can they be interesting for anybody? We can just
pretend that they are not there. Looks like a trivial solution for the
problem at hand.
^ permalink raw reply
* Re: [PATCH 7/8] tools lib bpf: fix maps resolution
From: Wangnan (F) @ 2016-11-08 22:08 UTC (permalink / raw)
To: Eric Leblond, netdev; +Cc: linux-kernel, ast
In-Reply-To: <20161016211834.11732-8-eric@regit.org>
Hi Eric,
During testing this patch I find a segfault, please see inline comment.
In addition, since both the BPF map array and map names should be done
after symbol table is collected, merging bpf_object__init_maps and
bpf_object__init_maps_name would be a good practice, making code
simpler.
So I prepare a new patch. Please have a look at:
http://lkml.kernel.org/g/20161108215734.28905-1-wangnan0@huawei.com
New version ensure not crashing in any case user provides a corrupted
maps section, including array of bpf maps, maps with different definition
structures and very short map definition.
Thank you.
On 2016/10/16 14:18, Eric Leblond wrote:
> It is not correct to assimilate the elf data of the maps section
> to an array of map definition. In fact the sizes differ. The
> offset provided in the symbol section has to be used instead.
>
> This patch fixes a bug causing a elf with two maps not to load
> correctly.
>
> Signed-off-by: Eric Leblond <eric@regit.org>
> ---
> tools/lib/bpf/libbpf.c | 50 +++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 1fe4532..f72628b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -186,6 +186,7 @@ struct bpf_program {
> struct bpf_map {
> int fd;
> char *name;
> + size_t offset;
> struct bpf_map_def def;
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> @@ -529,13 +530,6 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
>
> pr_debug("maps in %s: %zd bytes\n", obj->path, size);
>
> - obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
> - if (!obj->maps) {
> - pr_warning("alloc maps for object failed\n");
> - return -ENOMEM;
> - }
> - obj->nr_maps = nr_maps;
> -
> for (i = 0; i < nr_maps; i++) {
> struct bpf_map_def *def = &obj->maps[i].def;
>
> @@ -547,23 +541,42 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
> obj->maps[i].fd = -1;
>
> /* Save map definition into obj->maps */
> - *def = ((struct bpf_map_def *)data)[i];
> + *def = *(struct bpf_map_def *)(data + obj->maps[i].offset);
> }
Here, nr_maps is still size / sizeof(struct bpf_map_def), so obj->maps[i]
can be invalid.
> return 0;
> }
>
> static int
> -bpf_object__init_maps_name(struct bpf_object *obj)
> +bpf_object__init_maps_symbol(struct bpf_object *obj)
> {
> int i;
> + int nr_maps = 0;
> Elf_Data *symbols = obj->efile.symbols;
> + size_t map_idx = 0;
>
> if (!symbols || obj->efile.maps_shndx < 0)
> return -EINVAL;
>
> + /* get the number of maps */
> + for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
> + GElf_Sym sym;
> +
> + if (!gelf_getsym(symbols, i, &sym))
> + continue;
> + if (sym.st_shndx != obj->efile.maps_shndx)
> + continue;
> + nr_maps++;
> + }
> +
> + obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
> + if (!obj->maps) {
> + pr_warning("alloc maps for object failed\n");
> + return -ENOMEM;
> + }
> + obj->nr_maps = nr_maps;
> +
> for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
> GElf_Sym sym;
> - size_t map_idx;
> const char *map_name;
>
> if (!gelf_getsym(symbols, i, &sym))
> @@ -574,12 +587,12 @@ bpf_object__init_maps_name(struct bpf_object *obj)
> map_name = elf_strptr(obj->efile.elf,
> obj->efile.strtabidx,
> sym.st_name);
> - map_idx = sym.st_value / sizeof(struct bpf_map_def);
> if (map_idx >= obj->nr_maps) {
> pr_warning("index of map \"%s\" is buggy: %zu > %zu\n",
> map_name, map_idx, obj->nr_maps);
> continue;
> }
> + obj->maps[map_idx].offset = sym.st_value;
> obj->maps[map_idx].name = strdup(map_name);
> if (!obj->maps[map_idx].name) {
> pr_warning("failed to alloc map name\n");
> @@ -587,6 +600,7 @@ bpf_object__init_maps_name(struct bpf_object *obj)
> }
> pr_debug("map %zu is \"%s\"\n", map_idx,
> obj->maps[map_idx].name);
> + map_idx++;
> }
> return 0;
> }
> @@ -647,8 +661,6 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> data->d_buf,
> data->d_size);
> else if (strcmp(name, "maps") == 0) {
> - err = bpf_object__init_maps(obj, data->d_buf,
> - data->d_size);
> obj->efile.maps_shndx = idx;
> } else if (sh.sh_type == SHT_SYMTAB) {
> if (obj->efile.symbols) {
> @@ -698,8 +710,16 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
> pr_warning("Corrupted ELF file: index of strtab invalid\n");
> return LIBBPF_ERRNO__FORMAT;
> }
> - if (obj->efile.maps_shndx >= 0)
> - err = bpf_object__init_maps_name(obj);
> + if (obj->efile.maps_shndx >= 0) {
> + Elf_Data *data;
> + err = bpf_object__init_maps_symbol(obj);
> + if (err)
> + goto out;
> +
> + scn = elf_getscn(elf, obj->efile.maps_shndx);
> + data = elf_getdata(scn, 0);
> + err = bpf_object__init_maps(obj, data->d_buf, data->d_size);
> + }
> out:
> return err;
> }
^ permalink raw reply
* KASAN & the vmalloc area
From: Dmitry Vyukov @ 2016-11-08 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108190302.GH15297@leverpostej>
On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> I see a while back [1] there was a discussion of what to do about KASAN
> and vmapped stacks, but it doesn't look like that was solved, judging by
> the vmapped stacks pull [2] for v4.9.
>
> I wondered whether anyone had looked at that since?
>
> I have an additional reason to want to dynamically allocate the vmalloc
> area shadow: it turns out that KASAN currently interacts rather poorly
> with the arm64 ptdump code.
>
> When KASAN is selected, we allocate shadow for the whole vmalloc area,
> using common zero pte, pmd, pud tables. Walking over these in the ptdump
> code takes a *very* long time (I've seen up to 15 minutes with
> KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that
> long, too.
>
> If I don't allocate vmalloc shadow (and remove the apparently pointlesss
> shadow of the shadow area), and only allocate shadow for the image,
> fixmap, vmemmap and so on, that delay gets cut to a few seconds, which
> is tolerable for a debug configuration...
>
> ... however, things blow up when the kernel touches vmalloc'd memory for
> the first time, as we don't install shadow for that dynamically.
I've seen the same iteration slowness problem on x86 with
CONFIG_DEBUG_RODATA which walks all pages. The is about 1 minute, but
it is enough to trigger rcu stall warning.
The zero pud and vmalloc-ed stacks looks like different problems.
To overcome the slowness we could map zero shadow for vmalloc area lazily.
However for vmalloc-ed stacks we need to map actual memory, because
stack instrumentation will read/write into the shadow. One downside
here is that vmalloc shadow can be as large as 1:1 (if we allocate 1
page in vmalloc area we need to allocate 1 page for shadow).
Re slowness: could we just skip the KASAN zero puds (the top level)
while walking? Can they be interesting for anybody? We can just
pretend that they are not there. Looks like a trivial solution for the
problem at hand.
^ permalink raw reply
* [PATCH v5] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: chris.roth @ 2016-11-08 22:08 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel, artjom.simon, gregkh
Cc: Allan Chou, Chris Roth
In-Reply-To: <CAPZMiRa0kYyPFQ77L5y4NgxxH85iuMAjODV2iCzd-5OjyGfNuw@mail.gmail.com>
From: Allan Chou <allan@asix.com.tw>
Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610).
Patch verified on x64 linux kernel 4.7.4, 4.8.6, 4.9-rc4 systems
with the Kensington SD4600P USB-C Universal Dock with Power,
which uses the Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge
Controller.
A similar patch was signed-off and tested-by Allan Chou
<allan@asix.com.tw> on 2015-12-01.
Allan verified his similar patch on x86 Linux kernel 4.1.6 system
with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
Tested-by: Allan Chou <allan@asix.com.tw>
Tested-by: Chris Roth <chris.roth@usask.ca>
Tested-by: Artjom Simon <artjom.simon@gmail.com>
Signed-off-by: Allan Chou <allan@asix.com.tw>
Signed-off-by: Chris Roth <chris.roth@usask.ca>
---
Changes in v4, v5:
- Add verification of patch on 4.8.6, 4.9-rc4 (v4)
- Add tester Artjom Simon <artjom.simon@gmail.com> (v4)
- Reformat spaces to tabs (v5)
drivers/net/usb/ax88179_178a.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..8a6675d 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1656,6 +1656,19 @@ static const struct driver_info ax88178a_info = {
.tx_fixup = ax88179_tx_fixup,
};
+static const struct driver_info cypress_GX3_info = {
+ .description = "Cypress GX3 SuperSpeed to Gigabit Ethernet Controller",
+ .bind = ax88179_bind,
+ .unbind = ax88179_unbind,
+ .status = ax88179_status,
+ .link_reset = ax88179_link_reset,
+ .reset = ax88179_reset,
+ .stop = ax88179_stop,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .rx_fixup = ax88179_rx_fixup,
+ .tx_fixup = ax88179_tx_fixup,
+};
+
static const struct driver_info dlink_dub1312_info = {
.description = "D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter",
.bind = ax88179_bind,
@@ -1718,6 +1731,10 @@ static const struct usb_device_id products[] = {
USB_DEVICE(0x0b95, 0x178a),
.driver_info = (unsigned long)&ax88178a_info,
}, {
+ /* Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller */
+ USB_DEVICE(0x04b4, 0x3610),
+ .driver_info = (unsigned long)&cypress_GX3_info,
+}, {
/* D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter */
USB_DEVICE(0x2001, 0x4a00),
.driver_info = (unsigned long)&dlink_dub1312_info,
--
2.7.4
^ permalink raw reply related
* + kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch added to -mm tree
From: akpm @ 2016-11-08 22:07 UTC (permalink / raw)
To: bhe, anderson, ats-kumagai, d.hatayama, dyoung, ebiederm, hpa,
keescook, mingo, panand, surovegin, takahiro.akashi, tglx,
thgarnie, vgoyal, xlpang, mm-commits
The patch titled
Subject: kexec: export the value of phys_base instead of symbol address
has been added to the -mm tree. Its filename is
kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Baoquan He <bhe@redhat.com>
Subject: kexec: export the value of phys_base instead of symbol address
Currently in x86_64, the symbol address of phys_base is exported to
vmcoreinfo. Dave Anderson complained this is really useless for his Crash
implementation. Because in user-space utility Crash and Makedumpfile
which exported vmcore information is mainly used for, value of phys_base
is needed to covert virtual address of exported kernel symbol to physical
address. Especially init_level4_pgt, if we want to access and go over the
page table to look up a PA corresponding to VA, firstly we need calculate
page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;
Now in Crash and Makedumpfile, we have to analyze the vmcore elf program
header to get value of phys_base. As Dave said, it would be preferable if
it were readily availabl in vmcoreinfo rather than depending upon the
PT_LOAD semantics.
Hence in this patch change to export the value of phys_base instead of its
virtual address.
And people also complained that KERNEL_IMAGE_SIZE exporting is x86_64
only, should be moved into arch dependent function
arch_crash_save_vmcoreinfo. Do the moving in this patch.
Link: http://lkml.kernel.org/r/1478568596-30060-2-git-send-email-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Xunlei Pang <xlpang@redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Eugene Surovegin <surovegin@google.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>
Cc: Dave Anderson <anderson@redhat.com>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 3 ++-
kernel/kexec_core.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
diff -puN arch/x86/kernel/machine_kexec_64.c~kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address arch/x86/kernel/machine_kexec_64.c
--- a/arch/x86/kernel/machine_kexec_64.c~kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address
+++ a/arch/x86/kernel/machine_kexec_64.c
@@ -328,7 +328,7 @@ void machine_kexec(struct kimage *image)
void arch_crash_save_vmcoreinfo(void)
{
- VMCOREINFO_SYMBOL(phys_base);
+ VMCOREINFO_NUMBER(phys_base);
VMCOREINFO_SYMBOL(init_level4_pgt);
#ifdef CONFIG_NUMA
@@ -337,6 +337,7 @@ void arch_crash_save_vmcoreinfo(void)
#endif
vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
kaslr_offset());
+ VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
}
/* arch-dependent functionality related to kexec file-based syscall */
diff -puN kernel/kexec_core.c~kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address kernel/kexec_core.c
--- a/kernel/kexec_core.c~kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address
+++ a/kernel/kexec_core.c
@@ -1467,9 +1467,6 @@ static int __init crash_save_vmcoreinfo_
#endif
VMCOREINFO_NUMBER(PG_head_mask);
VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
-#ifdef CONFIG_X86
- VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
-#endif
#ifdef CONFIG_HUGETLB_PAGE
VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
#endif
_
Patches currently in -mm which might be from bhe@redhat.com are
revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch
kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch
^ permalink raw reply
* + revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch added to -mm tree
From: akpm @ 2016-11-08 22:07 UTC (permalink / raw)
To: bhe, anderson, ats-kumagai, d.hatayama, dyoung, ebiederm, hpa,
keescook, mingo, panand, surovegin, takahiro.akashi, tglx,
thgarnie, vgoyal, xlpang, mm-commits
The patch titled
Subject: Revert "kdump, vmcoreinfo: report memory sections virtual addresses"
has been added to the -mm tree. Its filename is
revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Baoquan He <bhe@redhat.com>
Subject: Revert "kdump, vmcoreinfo: report memory sections virtual addresses"
This reverts 0549a3c02efb3507 ("kdump, vmcoreinfo: report memory sections
virtual addresses").
Commit 0549a3c tells the userspace utility makedumpfile the randomized
base address of these memmory sections when mm kaslr is enabled. However
the following patch "kexec: export the value of phys_base instead of
symbol address" makes makedumpfile not need these addresses any more.
Besides we should use VMCOREINFO_NUMBER to export the value of the
variable so that we can use the existing number_table mechanism of
Makedumpfile to fetch it. So revert it now. If needed we can add it later.
http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
Link: http://lkml.kernel.org/r/1478568596-30060-1-git-send-email-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Xunlei Pang <xlpang@redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Eugene Surovegin <surovegin@google.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>
Cc: Dave Anderson <anderson@redhat.com>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/machine_kexec_64.c | 3 ---
include/linux/kexec.h | 6 ------
2 files changed, 9 deletions(-)
diff -puN arch/x86/kernel/machine_kexec_64.c~revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses arch/x86/kernel/machine_kexec_64.c
--- a/arch/x86/kernel/machine_kexec_64.c~revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses
+++ a/arch/x86/kernel/machine_kexec_64.c
@@ -337,9 +337,6 @@ void arch_crash_save_vmcoreinfo(void)
#endif
vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
kaslr_offset());
- VMCOREINFO_PAGE_OFFSET(PAGE_OFFSET);
- VMCOREINFO_VMALLOC_START(VMALLOC_START);
- VMCOREINFO_VMEMMAP_START(VMEMMAP_START);
}
/* arch-dependent functionality related to kexec file-based syscall */
diff -puN include/linux/kexec.h~revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses include/linux/kexec.h
--- a/include/linux/kexec.h~revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses
+++ a/include/linux/kexec.h
@@ -259,12 +259,6 @@ phys_addr_t paddr_vmcoreinfo_note(void);
vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
#define VMCOREINFO_CONFIG(name) \
vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
-#define VMCOREINFO_PAGE_OFFSET(value) \
- vmcoreinfo_append_str("PAGE_OFFSET=%lx\n", (unsigned long)value)
-#define VMCOREINFO_VMALLOC_START(value) \
- vmcoreinfo_append_str("VMALLOC_START=%lx\n", (unsigned long)value)
-#define VMCOREINFO_VMEMMAP_START(value) \
- vmcoreinfo_append_str("VMEMMAP_START=%lx\n", (unsigned long)value)
extern struct kimage *kexec_image;
extern struct kimage *kexec_crash_image;
_
Patches currently in -mm which might be from bhe@redhat.com are
revert-kdump-vmcoreinfo-report-memory-sections-virtual-addresses.patch
kexec-change-to-export-the-value-of-phys_base-instead-of-symbol-address.patch
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64: Fix checksum folding in csum_tcpudp_nofold and ip_fast_csum_nofold
From: Paul Mackerras @ 2016-11-08 22:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <878tsul9jh.fsf@concordia.ellerman.id.au>
On Tue, Nov 08, 2016 at 06:23:30PM +1100, Michael Ellerman wrote:
> Paul Mackerras <paulus@ozlabs.org> writes:
>
> > These functions compute an IP checksum by computing a 64-bit sum and
> > folding it to 32 bits (the "nofold" in their names refers to folding
> > down to 16 bits). However, doing (u32) (s + (s >> 32)) is not
> > sufficient to fold a 64-bit sum to 32 bits correctly. The addition
> > can produce a carry out from bit 31, which needs to be added in to
> > the sum to produce the correct result.
> >
> > To fix this, we copy the from64to32() function from lib/checksum.c
> > and use that.
>
> This seems to have been broken since ~forever. Do we just not hit that
> case very often, or do we just incorrectly report checksum failures?
I think there would be about a 1 in a billion chance of hitting it by
chance, though you could probably construct a test case that would hit
it every time. If you did hit it in real life it would result in a
packet being dropped and presumably retransmitted, and I expect that
the IP header of the retransmitted packet would be sufficiently
different (i.e. different id field or something) that it wouldn't hit
the bug a second time.
> Should it go to stable?
Probably... though nobody has actually noticed a problem in real life
and pinned it down to this.
Paul.
^ permalink raw reply
* [Buildroot] genconfig/unconditonally include external.mk
From: Arnout Vandecappelle @ 2016-11-08 22:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <98c173fef60c7635dee3883c3bb90271@walle.cc>
On 08-11-16 13:38, Michael Walle wrote:
> Am 2016-11-08 13:02, schrieb Arnout Vandecappelle:
>> On 08-11-16 11:59, Michael Walle wrote:
>>> Am 2016-11-08 02:22, schrieb Arnout Vandecappelle:
>>> mhh, ok, but i guess having additional make targets would be more appealing.
>>> Esp. if you need some variables defined by buildroot.
>>
>> What variables defined by Buildroot could you possibly need? Since you're
>> making a defconfig, you have no .config available. The only variable that you
>> may want to use is $(O), but that one you anyway have to pass on the command
>> line.
>
> Ahh, I thought of the support/kconfig/merge_config.sh for which I would need
> TOPDIR. I did just a quick test and it turns out, that I cannot use it as is,
> because it does an alldefconfig which isn't supported by buildroot (yet? dunno).
Shouldn't that be olddefconfig (which is supported by buildroot)?
>
>
>> So pass it as an argument to your merge script. Something like
>>
>> ./genconfig <config-spec> [<path-to-output>]
>>
>> It would actually be great if we would have a script like that in Buildroot
>> that can be used generically.
>
>
> Lets say we have a generic genconfig inside buildroot. Would it be only for
> external users or would you use it to generate similar defconfig files inside
> buildroot? And in the latter case, how would you do it?
Both, I think. To use it to generate defconfig files inside buildroot, we'd add
something in the documentation explaining how you can create an extended board
config by calling the script to combine the base config with an extension config.
[snip]
>> The problem is that we don't see a sensible use case for it. When we make
>> changes we want to make sure that we don't break any use cases, so we really
>> need to know what the use cases are. And use cases that can be solved
>> differently don't count :-)
>
> Yeah and its really ok, because otherwise buildroot will be more and more
> complex, and I don't want it to become another yocto :o)
We started using pseudo, and firing up make takes almost as long as firing up
bitbake, so I'm afraid we're not that far off...
> Nonetheless, the
> genconfig wasn't the only use case for this, but also an external help command,
> which also only makes sense, if you have own makefile targets, mhh.
> And I really liked the idea of having a target "my_defconfig" where my_defconfig
> doesn't have to be a file but some script which do the defconfig. IMHO, from a
> users perspective it makes sense to have the same kind of target (*_defconfig).
We have a (IMHO healthy) resistance against such "frivolous features", but if
there is enough push for it they eventually tend to come through. Cfr.
BR2_EXTERNAL, for instance. Keep on posting patches and talking to people!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* Re: [PATCH v5 2/2] transport: add protocol policy config option
From: Brandon Williams @ 2016-11-08 22:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, sbeller, bburky, jrnieder
In-Reply-To: <20161108220426.bqvmmjr54w7btgih@sigill.intra.peff.net>
On 11/08, Jeff King wrote:
> On Mon, Nov 07, 2016 at 01:51:02PM -0800, Brandon Williams wrote:
>
> > Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to
> > specify a whitelist of protocols to be used in clone/fetch/push
> > commands. This patch introduces new configuration options for more
> > fine-grained control for allowing/disallowing protocols. This also has
> > the added benefit of allowing easier construction of a protocol
> > whitelist on systems where setting an environment variable is
> > non-trivial.
>
> This v5 looks good to me (both patches 1 and 2).
Thanks again for the help with this series!
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH 0/4] musb fixes for v4.9-rc cycle
From: Tony Lindgren @ 2016-11-08 22:05 UTC (permalink / raw)
To: Ladislav Michl
Cc: Bin Liu, Boris Brezillon, Greg Kroah-Hartman, Andreas Kemnade,
Felipe Balbi, George Cherian, Kishon Vijay Abraham I,
Ivaylo Dimitrov, Johan Hovold, Laurent Pinchart, Sergei Shtylyov,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161108171951.GA27533-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
* Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [161108 10:20]:
> On Tue, Nov 08, 2016 at 07:55:50AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161108 07:50]:
> > > Weird, I have not figured out what happens there..
> > >
> > > The only thing I'm still wondering about is if phy-twl4030-usb.c
> > > is losing ID pin interrupts occasionally but have not been
> > > able to verify that. Maybe try the following additional patch
> > > and see if it makes any difference?
> >
> > And eventually the glue layers only should need to do this on
> > init:
> >
> > pm_runtime_enable(glue->dev);
> >
> > And this on the exit path:
> >
> > pm_runtime_disable(glue->dev);
> >
> > And musb core as the child device should keep things awake
> > when needed.
>
> Tested your patch, does not work, does not trigger "USB link status err"
> both without and with pm_runtime_enable/disable.
OK. The patch below still works for me with musb_core.c
autosuspend_delay set to 100. Also works with it set to 10.
Note that we had two timeouts without this.. Can you try
playing with the timeout in musb_core.c and see if that
helps?
Regards,
Tony
8< ------------------
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1898,8 +1898,7 @@ static void musb_pm_runtime_check_session(struct musb *musb)
musb->quirk_retries = 3;
} else {
musb_dbg(musb, "Allow PM with no session: %02x", devctl);
- pm_runtime_mark_last_busy(musb->controller);
- pm_runtime_put_autosuspend(musb->controller);
+ pm_runtime_put_sync_suspend(musb->controller);
}
musb->session = s;
@@ -2268,7 +2267,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
* 500 ms for some margin.
*/
pm_runtime_use_autosuspend(musb->controller);
- pm_runtime_set_autosuspend_delay(musb->controller, 500);
+ pm_runtime_set_autosuspend_delay(musb->controller, 100);
pm_runtime_enable(musb->controller);
pm_runtime_get_sync(musb->controller);
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -513,17 +513,18 @@ static int omap2430_probe(struct platform_device *pdev)
}
pm_runtime_enable(glue->dev);
- pm_runtime_use_autosuspend(glue->dev);
- pm_runtime_set_autosuspend_delay(glue->dev, 100);
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err2;
+ goto err3;
}
return 0;
+err3:
+ pm_runtime_disable(glue->dev);
+
err2:
platform_device_put(musb);
@@ -535,10 +536,7 @@ static int omap2430_remove(struct platform_device *pdev)
{
struct omap2430_glue *glue = platform_get_drvdata(pdev);
- pm_runtime_get_sync(glue->dev);
platform_device_unregister(glue->musb);
- pm_runtime_put_sync(glue->dev);
- pm_runtime_dont_use_autosuspend(glue->dev);
pm_runtime_disable(glue->dev);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Keller, Jacob E @ 2016-11-08 22:04 UTC (permalink / raw)
To: netdev@vger.kernel.org, richardcochran@gmail.com
Cc: tglx@linutronix.de, Manfred.Rudigier@omicron.at,
ulrik.debie-os@e2big.org, stefan.sorensen@spectralink.com,
davem@davemloft.net, Kirsher, Jeffrey T, john.stultz@linaro.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <b1d732324e0b1960b294e90ca5eb2a31b6559188.1478526333.git.richardcochran@gmail.com>
On Tue, 2016-11-08 at 22:49 +0100, Richard Cochran wrote:
> The 82580 and related devices offer a frequency resolution of about
> 0.029 ppb. This patch lets users of the device benefit from the
> increased frequency resolution when tuning the clock.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> ---
Additionally, what about min/max frequency check? Wouldn't this need to
be updated for the new adjfine operation?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams
From: Sören Brinkmann @ 2016-11-08 18:32 UTC (permalink / raw)
To: Moritz Fischer
Cc: linux-kernel, moritz.fischer.private, atull, michal.simek,
linux-arm-kernel, julia
In-Reply-To: <20161107001326.7395-4-moritz.fischer@ettus.com>
On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote:
> Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching
> capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly
> decryption of an encrypted bitstream.
>
> If the system is not booted in secure mode AES & HMAC units
> are disabled by the boot ROM, therefore the capability
> is not available.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/fpga/fpga-mgr.c | 7 +++++++
> drivers/fpga/zynq-fpga.c | 21 +++++++++++++++++++--
> include/linux/fpga/fpga-mgr.h | 2 ++
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 98230b7..e4d08e1 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -61,6 +61,12 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> return -ENOTSUPP;
> }
>
> + if (flags & FPGA_MGR_DECRYPT_BITSTREAM &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_DECRYPT, mgr->caps)) {
> + dev_err(dev, "Bitstream decryption not supported\n");
> + return -ENOTSUPP;
> + }
> +
> /*
> * Call the low level driver's write_init function. This will do the
> * device-specific things to get the FPGA into the state where it is
> @@ -170,6 +176,7 @@ static const char * const state_str[] = {
> static const char * const cap_str[] = {
> [FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
> [FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
> + [FPGA_MGR_CAP_DECRYPT] = "Decrypt bitstream on the fly",
> };
>
> static ssize_t name_show(struct device *dev,
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index 1d37ff0..0aa4705 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -71,6 +71,10 @@
> #define CTRL_PCAP_PR_MASK BIT(27)
> /* Enable PCAP */
> #define CTRL_PCAP_MODE_MASK BIT(26)
> +/* Needed to reduce clock rate for secure config */
> +#define CTRL_PCAP_RATE_EN_MASK BIT(25)
> +/* System booted in secure mode */
> +#define CTRL_SEC_EN_MASK BIT(7)
>
> /* Miscellaneous Control Register bit definitions */
> /* Internal PCAP loopback */
> @@ -252,12 +256,20 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> /* set configuration register with following options:
> * - enable PCAP interface
> - * - set throughput for maximum speed
> + * - set throughput for maximum speed (if we're not decrypting)
> * - set CPU in user mode
> */
> ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> - zynq_fpga_write(priv, CTRL_OFFSET,
> + if (flags & FPGA_MGR_DECRYPT_BITSTREAM) {
> + zynq_fpga_write(priv, CTRL_OFFSET,
> + (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK |
> + CTRL_PCAP_RATE_EN_MASK | ctrl));
> +
> + } else {
> + ctrl &= ~CTRL_PCAP_RATE_EN_MASK;
> + zynq_fpga_write(priv, CTRL_OFFSET,
> (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK | ctrl));
> + }
Minor nit:
Assuming that there may be more caps to check to come, wouldn't it be
slightly easier to write this in a way like?:
if (flags & SOME_FLAG)
ctrl |= FOO;
if (flags & SOME_OTHER_FLAG)
ctrl |= BAR;
zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
i.e. moving the fpga_write outside of the conditionals.
Sören
^ permalink raw reply
* Re: [PATCH v5 2/2] transport: add protocol policy config option
From: Jeff King @ 2016-11-08 22:04 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, bburky, jrnieder
In-Reply-To: <1478555462-132573-2-git-send-email-bmwill@google.com>
On Mon, Nov 07, 2016 at 01:51:02PM -0800, Brandon Williams wrote:
> Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to
> specify a whitelist of protocols to be used in clone/fetch/push
> commands. This patch introduces new configuration options for more
> fine-grained control for allowing/disallowing protocols. This also has
> the added benefit of allowing easier construction of a protocol
> whitelist on systems where setting an environment variable is
> non-trivial.
This v5 looks good to me (both patches 1 and 2).
-Peff
^ permalink raw reply
* [Intel-wired-lan] [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Keller, Jacob E @ 2016-11-08 22:04 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <b1d732324e0b1960b294e90ca5eb2a31b6559188.1478526333.git.richardcochran@gmail.com>
On Tue, 2016-11-08 at 22:49 +0100, Richard Cochran wrote:
> The 82580 and related devices offer a frequency resolution of about
> 0.029 ppb.??This patch lets users of the device benefit from the
> increased frequency resolution when tuning the clock.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> ---
Additionally, what about min/max frequency check? Wouldn't this need to
be updated for the new adjfine operation?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Keller, Jacob E @ 2016-11-08 22:02 UTC (permalink / raw)
To: netdev@vger.kernel.org, richardcochran@gmail.com
Cc: tglx@linutronix.de, Manfred.Rudigier@omicron.at,
ulrik.debie-os@e2big.org, stefan.sorensen@spectralink.com,
davem@davemloft.net, Kirsher, Jeffrey T, john.stultz@linaro.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <b1d732324e0b1960b294e90ca5eb2a31b6559188.1478526333.git.richardcochran@gmail.com>
On Tue, 2016-11-08 at 22:49 +0100, Richard Cochran wrote:
> The 82580 and related devices offer a frequency resolution of about
> 0.029 ppb. This patch lets users of the device benefit from the
> increased frequency resolution when tuning the clock.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> ---
> drivers/net/ethernet/intel/igb/igb_ptp.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
> b/drivers/net/ethernet/intel/igb/igb_ptp.c
> index a7895c4..c30eea8 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ptp.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
> @@ -226,7 +226,7 @@ static int igb_ptp_adjfreq_82576(struct
> ptp_clock_info *ptp, s32 ppb)
> return 0;
> }
>
> -static int igb_ptp_adjfreq_82580(struct ptp_clock_info *ptp, s32
> ppb)
> +static int igb_ptp_adjfine_82580(struct ptp_clock_info *ptp, long
> scaled_ppm)
> {
> struct igb_adapter *igb = container_of(ptp, struct
> igb_adapter,
> ptp_caps);
> @@ -235,13 +235,13 @@ static int igb_ptp_adjfreq_82580(struct
> ptp_clock_info *ptp, s32 ppb)
> u64 rate;
> u32 inca;
>
> - if (ppb < 0) {
> + if (scaled_ppm < 0) {
> neg_adj = 1;
> - ppb = -ppb;
> + scaled_ppm = -scaled_ppm;
> }
> - rate = ppb;
> - rate <<= 26;
> - rate = div_u64(rate, 1953125);
> + rate = scaled_ppm;
> + rate <<= 13;
> + rate = div_u64(rate, 15625);
>
I'm curious how you generate the new math here, since this can be
tricky, and I could use more examples in order to port to some of the
other drivers implementations. I'm not quit sure how to handle the
value when the lower 16 bits are fractional.
Thanks,
Jake
> inca = rate & INCVALUE_MASK;
> if (neg_adj)
> @@ -1103,7 +1103,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
> adapter->ptp_caps.max_adj = 62499999;
> adapter->ptp_caps.n_ext_ts = 0;
> adapter->ptp_caps.pps = 0;
> - adapter->ptp_caps.adjfreq = igb_ptp_adjfreq_82580;
> + adapter->ptp_caps.adjfine = igb_ptp_adjfine_82580;
> adapter->ptp_caps.adjtime = igb_ptp_adjtime_82576;
> adapter->ptp_caps.gettime64 = igb_ptp_gettime_82576;
> adapter->ptp_caps.settime64 = igb_ptp_settime_82576;
> @@ -1131,7 +1131,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
> adapter->ptp_caps.n_pins = IGB_N_SDP;
> adapter->ptp_caps.pps = 1;
> adapter->ptp_caps.pin_config = adapter->sdp_config;
> - adapter->ptp_caps.adjfreq = igb_ptp_adjfreq_82580;
> + adapter->ptp_caps.adjfine = igb_ptp_adjfine_82580;
> adapter->ptp_caps.adjtime = igb_ptp_adjtime_i210;
> adapter->ptp_caps.gettime64 = igb_ptp_gettime_i210;
> adapter->ptp_caps.settime64 = igb_ptp_settime_i210;
^ permalink raw reply
* [Intel-wired-lan] [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency method.
From: Keller, Jacob E @ 2016-11-08 22:02 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <b1d732324e0b1960b294e90ca5eb2a31b6559188.1478526333.git.richardcochran@gmail.com>
On Tue, 2016-11-08 at 22:49 +0100, Richard Cochran wrote:
> The 82580 and related devices offer a frequency resolution of about
> 0.029 ppb.??This patch lets users of the device benefit from the
> increased frequency resolution when tuning the clock.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> ---
> ?drivers/net/ethernet/intel/igb/igb_ptp.c | 16 ++++++++--------
> ?1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
> b/drivers/net/ethernet/intel/igb/igb_ptp.c
> index a7895c4..c30eea8 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ptp.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
> @@ -226,7 +226,7 @@ static int igb_ptp_adjfreq_82576(struct
> ptp_clock_info *ptp, s32 ppb)
> ? return 0;
> ?}
> ?
> -static int igb_ptp_adjfreq_82580(struct ptp_clock_info *ptp, s32
> ppb)
> +static int igb_ptp_adjfine_82580(struct ptp_clock_info *ptp, long
> scaled_ppm)
> ?{
> ? struct igb_adapter *igb = container_of(ptp, struct
> igb_adapter,
> ? ???????ptp_caps);
> @@ -235,13 +235,13 @@ static int igb_ptp_adjfreq_82580(struct
> ptp_clock_info *ptp, s32 ppb)
> ? u64 rate;
> ? u32 inca;
> ?
> - if (ppb < 0) {
> + if (scaled_ppm < 0) {
> ? neg_adj = 1;
> - ppb = -ppb;
> + scaled_ppm = -scaled_ppm;
> ? }
> - rate = ppb;
> - rate <<= 26;
> - rate = div_u64(rate, 1953125);
> + rate = scaled_ppm;
> + rate <<= 13;
> + rate = div_u64(rate, 15625);
> ?
I'm curious how you generate the new math here, since this can be
tricky, and I could use more examples in order to port to some of the
other drivers implementations. I'm not quit sure how to handle the
value when the lower 16 bits are fractional.
Thanks,
Jake
> ? inca = rate & INCVALUE_MASK;
> ? if (neg_adj)
> @@ -1103,7 +1103,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
> ? adapter->ptp_caps.max_adj = 62499999;
> ? adapter->ptp_caps.n_ext_ts = 0;
> ? adapter->ptp_caps.pps = 0;
> - adapter->ptp_caps.adjfreq = igb_ptp_adjfreq_82580;
> + adapter->ptp_caps.adjfine = igb_ptp_adjfine_82580;
> ? adapter->ptp_caps.adjtime = igb_ptp_adjtime_82576;
> ? adapter->ptp_caps.gettime64 = igb_ptp_gettime_82576;
> ? adapter->ptp_caps.settime64 = igb_ptp_settime_82576;
> @@ -1131,7 +1131,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
> ? adapter->ptp_caps.n_pins = IGB_N_SDP;
> ? adapter->ptp_caps.pps = 1;
> ? adapter->ptp_caps.pin_config = adapter->sdp_config;
> - adapter->ptp_caps.adjfreq = igb_ptp_adjfreq_82580;
> + adapter->ptp_caps.adjfine = igb_ptp_adjfine_82580;
> ? adapter->ptp_caps.adjtime = igb_ptp_adjtime_i210;
> ? adapter->ptp_caps.gettime64 = igb_ptp_gettime_i210;
> ? adapter->ptp_caps.settime64 = igb_ptp_settime_i210;
^ permalink raw reply
* Re: [PATCH v3 1/8] exec: introduce cred_guard_light
From: Kees Cook @ 2016-11-08 22:02 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Eric W. Biederman, Jann Horn, Alexander Viro, Roland McGrath,
John Johansen, James Morris, Serge E. Hallyn, Paul Moore,
Stephen Smalley, Eric Paris, Casey Schaufler, Andrew Morton,
Janis Danisevskis, Seth Forshee, Thomas Gleixner,
Benjamin LaHaise, Ben Hutchings, Andy Lutomirski, Linus Torvalds,
Krister Johansen, linux-fsdevel@vger.kernel.org,
linux-security-module, security@kernel.org
In-Reply-To: <20161104184505.GA21320@redhat.com>
On Fri, Nov 4, 2016 at 11:45 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> Eric, I hope you see my emails, I got the "Undelivered Mail Returned to Sender"
> ...
> This is the mail system at host mail.kernel.org.
> ...
> <ebiederm@xmission.com> (expanded from <security@kernel.org>): host
> mx.xmission.com[166.70.12.20] said: 550-XM-RJCT16: SPF Failure
> (ip=198.145.29.136, frm=oleg@redhat.com, 550 result=fail) (in reply to RCPT
> TO command)
>
> right now I have no idea what does this mean.
This is a problem for Google folks too sometimes. This is saying that
xmission.com is checking redhat.com's SPF records and refusing to let
kernel.org deliver email as if it were redhat.com (due to
security@kernel.org being an alias not a mailing list). There aren't
good solutions for this, but best I've found is to have my
security@kernel.org alias be a @kernel.org address instead of an
@google.com address...
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: master branch merges must pass unit tests
From: Ken Dreyer @ 2016-11-08 22:01 UTC (permalink / raw)
To: Patrick Donnelly; +Cc: Sage Weil, Ceph Development
In-Reply-To: <CA+2bHPY=GQ-mXi_GpanXRefTmtrZxAee_eMATUpO-W+QhRpSZw@mail.gmail.com>
On Tue, Nov 8, 2016 at 2:56 PM, Patrick Donnelly <pdonnell@redhat.com> wrote:
> On Tue, Nov 8, 2016 at 4:49 PM, Sage Weil <sweil@redhat.com> wrote:
>> I enabled the github check that the unit tests pass in order to merge to
>> master. These tests still aren't completely reliable, but they're close,
>> and we'll make better progress if we start enforcing it now.
>>
>> Note that core developers can still override the check to merge if
>> it's necessary, but I encourage you to avoid doing so!
>
> Does this effect manual merges?
From what I've seen in GitHub, it is in force for both scenarios: the
web UI as well as "git push origin master"
- Ken
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.