return_address returns the address that is one level higher in the call
stack than requested in its argument, because level 0 corresponds to its
caller's return address. Use requested level as the number of stack
frames to skip.
This fixes the address reported by might_sleep and friends.
Cc: stable(a)vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
---
arch/xtensa/kernel/stacktrace.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/xtensa/kernel/stacktrace.c b/arch/xtensa/kernel/stacktrace.c
index 174c11f13bba..b9f82510c650 100644
--- a/arch/xtensa/kernel/stacktrace.c
+++ b/arch/xtensa/kernel/stacktrace.c
@@ -253,10 +253,14 @@ static int return_address_cb(struct stackframe *frame, void *data)
return 1;
}
+/*
+ * level == 0 is for the return address from the caller of this function,
+ * not from this function itself.
+ */
unsigned long return_address(unsigned level)
{
struct return_addr_data r = {
- .skip = level + 1,
+ .skip = level,
};
walk_stackframe(stack_pointer(NULL), return_address_cb, &r);
return r.addr;
--
2.11.0
On 4/4/19 11:12 AM, Dan Carpenter wrote:
> The "call" variable comes from the user in privcmd_ioctl_hypercall().
> It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
> elements. We need to put an upper bound on it to prevent an out of
> bounds access.
>
> Fixes: 1246ae0bb992 ("xen: add variable hypercall caller")
> Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
I am also adding stable(a)vger.kernel.org
-boris
> ---
> arch/x86/include/asm/xen/hypercall.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index de6f0d59a24f..2863c2026655 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -206,6 +206,9 @@ xen_single_call(unsigned int call,
> __HYPERCALL_DECLS;
> __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
>
> + if (call >= PAGE_SIZE / sizeof(hypercall_page[0]))
> + return -EINVAL;
> +
> asm volatile(CALL_NOSPEC
> : __HYPERCALL_5PARAM
> : [thunk_target] "a" (&hypercall_page[call])
When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but
not REGMAP_MMIO, so the kernel fails to link with an undefined reference
to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in
drivers/base/regmap/Kconfig.
This creates the following dependency loop:
drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
drivers/base/regmap/Kconfig:7: symbol REGMAP default is visible depending on REGMAP_MMIO
drivers/base/regmap/Kconfig:39: symbol REGMAP_MMIO is selected by SUNXI_SRAM
drivers/soc/sunxi/Kconfig:4: symbol SUNXI_SRAM is selected by USB_MUSB_SUNXI
drivers/usb/musb/Kconfig:63: symbol USB_MUSB_SUNXI depends on GENERIC_PHY
drivers/phy/Kconfig:7: symbol GENERIC_PHY is selected by PHY_BCM_NS_USB3
drivers/phy/broadcom/Kconfig:29: symbol PHY_BCM_NS_USB3 depends on MDIO_BUS
drivers/net/phy/Kconfig:12: symbol MDIO_BUS default is visible depending on PHYLIB
drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected by ARC_EMAC
drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
To fix the circular dependency, make USB_MUSB_SUNXI select GENERIC_PHY
instead of depending on it. This matches the use of GENERIC_PHY by all
but two other drivers.
Cc: <stable(a)vger.kernel.org> # 4.19
Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64")
Signed-off-by: Samuel Holland <samuel(a)sholland.org>
---
changes from v1:
- add stable@ and Fixes: tag
---
drivers/soc/sunxi/Kconfig | 1 +
drivers/usb/musb/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
index 353b07e40176..e84eb4e59f58 100644
--- a/drivers/soc/sunxi/Kconfig
+++ b/drivers/soc/sunxi/Kconfig
@@ -4,6 +4,7 @@
config SUNXI_SRAM
bool
default ARCH_SUNXI
+ select REGMAP_MMIO
help
Say y here to enable the SRAM controller support. This
device is responsible on mapping the SRAM in the sunXi SoCs
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index ad08895e78f9..c3dae7d5cb6e 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -66,7 +66,7 @@ config USB_MUSB_SUNXI
depends on NOP_USB_XCEIV
depends on PHY_SUN4I_USB
depends on EXTCON
- depends on GENERIC_PHY
+ select GENERIC_PHY
select SUNXI_SRAM
config USB_MUSB_DAVINCI
--
2.21.0
On Thu, Apr 4, 2019 at 4:09 PM Christian Brauner <christian(a)brauner.io> wrote:
>
> On Wed, Apr 03, 2019 at 07:08:47PM +0200, Matteo Croce wrote:
> > On Wed, Apr 3, 2019 at 6:40 PM Matteo Croce <mcroce(a)redhat.com> wrote:
> > >
> > > On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox <willy(a)infradead.org> wrote:
> > > >
> > > > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote:
> > > > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner <christian(a)brauner.io> wrote:
> > > > > > Yeah, maybe but it still feels cleaner and more obvious to just add:
> > > > > >
> > > > > > static long long_zero;
> > > > > >
> > > > > > given that most callers actually seem to want an (unsigned) int.
> > > > > >
> > > > > > I don't have a strong opinion though so if others feel that it's just a
> > > > > > waste of space consider it acked.
> > > > > >
> > > > >
> > > > > Well, given that the value is zero, in this expectional case we could
> > > > > avoid duplicating the symbol and save 4 bytes.
> > > > > What the maintainers think?
> > > >
> > > > If we care about saving four bytes, we could just pass the address of
> > > > ZERO_PAGE(0).
> > >
> > > That would work, work too, maybe it's a bit overkill.
> > > int zero is always there and it's static, so enlarging it to long
> > > should be a straightforward fix.
> > > Obviously we can't do it for other numbers, but we can alias it just
> > > for the zero case..
> > >
> > > Regards,
> > >
> > > --
> > > Matteo Croce
> > > per aspera ad upstream
> >
> > Anyway, I'm fine with both solutions, as I have other patches in the
>
> I think Matthew's idea gets us best of both worlds so I'd suggest to use
> it and resend the patch. You likely want to Cc stable(a)vger.kernel.org
> since the original patch this fixes got backported by Greg quite a bit
> since this was a rather long-standing issue. Please also Cc Andrew this
> time since he's likely going to pick it up.
>
> Thanks for the patch!
> Christian
So you mean using page_address(ZERO_PAGE(0)) ?
The idea is nice, but since struct ctl_table kern_table is declared as
global variable, how can I assign it to the structure?
GCC complains about 'initializer element is not constant', and
ZERO_PAGE(0)->virtual only works if WANT_PAGE_VIRTUAL.
Anyway, I'm preparing a treewide patch to move all "zero", "one" and
"int_max" to three single, const variables in fs/proc/proc_sysctl.c
as there are 200+ occourrences of them, so I'd rather keep this simple
to have it easily backported to stable.
--
Matteo Croce
per aspera ad upstream