* Re: [PATCH v3] drm: move allocation out of drm_get_format_name()
From: Eric Engestrom @ 2016-11-09 11:42 UTC (permalink / raw)
To: Eric Engestrom, linux-kernel, David Airlie, dri-devel,
Wei Yongjun, Daniel Vetter, Flora Cui, Gustavo Padovan,
Tom St Denis, Chunming Zhou, Thomas Hellstrom, Laurent Pinchart,
Sinclair Yeh, Xinliang Liu, Xinwei Kong, VMware Graphics,
Vitaly Prosyak, Alexandre Demers, Jani Nikula, intel-gfx,
Emily Deng, Colin Ian King
In-Reply-To: <20161109011325.hvvfsvpq734nduxd@phenom.ffwll.local>
On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 12:17:52AM +0000, Eric Engestrom wrote:
> > > The function's behaviour was changed in 90844f00049e, without changing
> > > its signature, causing people to keep using it the old way without
> > > realising they were now leaking memory.
> > > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > > atomic contexts, breaking them.
> > >
> > > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > > to make them cleanup the memory afterwards, let's change the function's
> > > signature by having the caller take care of the memory and passing it to
> > > the function.
> > > The new parameter is a single-field struct in order to enforce the size
> > > of its buffer and help callers to correctly manage their memory.
> > >
> > > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > > Cc: Rob Clark <robdclark@gmail.com>
> > > Cc: Christian König <christian.koenig@amd.com>
> > > Acked-by: Christian König <christian.koenig@amd.com>
> > > Acked-by: Rob Clark <robdclark@gmail.com>
> > > Acked-by: Sinclair Yeh <syeh@vmware.com> (vmwgfx)
> > > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> > > Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Eric Engestrom <eric@engestrom.ch>
> > > ---
> > > v3 - fix "Fixes" tag, replace it with an actual commit message
> > > - collect ack & r-b
> > >
> > > v2 - use single-field struct instead of typedef to let the compiler
> > > enforce the type (Christian König)
> >
> > Applied to drm-misc, thanks.
>
> Well, had to drop it again since it didn't compile:
>
>
> CC [M] drivers/gpu/drm/drm_blend.o
> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function ‘drm_get_format_name’
> drm_get_format_name(fb->pixel_format));
> ^~~~~~~~~~~~~~~~~~~
> In file included from ./include/drm/drmP.h:71:0,
> from drivers/gpu/drm/drm_atomic.c:29:
> ./include/drm/drm_fourcc.h:65:7: note: declared here
> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
> ^~~~~~~~~~~~~~~~~~~
>
> Can you pls rebase onto drm-misc or linux-next or something?
That was based on airlied/drm-next (last fetched on Sunday I think),
I can rebase it on drm-misc if it helps, but it seems older than
drm-next.
Should I just rebase on top of current head of drm-next?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 4.4 56/69] powerpc/ptrace: Fix out of bounds array access warning
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Khem Raj, Kees Cook, Michael Ellerman,
Segher Boessenkool, Aaro Koskinen, Olof Johansson, Arnd Bergmann
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Khem Raj <raj.khem@gmail.com>
commit 1e407ee3b21f981140491d5b8a36422979ca246f upstream.
gcc-6 correctly warns about a out of bounds access
arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds]
offsetof(struct thread_fp_state, fpr[32][0]));
^
check the end of array instead of beginning of next element to fix this
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -376,7 +376,7 @@ static int fpr_get(struct task_struct *t
#else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
- offsetof(struct thread_fp_state, fpr[32][0]));
+ offsetof(struct thread_fp_state, fpr[32]));
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
@@ -404,7 +404,7 @@ static int fpr_set(struct task_struct *t
return 0;
#else
BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
- offsetof(struct thread_fp_state, fpr[32][0]));
+ offsetof(struct thread_fp_state, fpr[32]));
return user_regset_copyin(&pos, &count, &kbuf, &ubuf,
&target->thread.fp_state, 0, -1);
^ permalink raw reply
* [PATCH 4.4 58/69] mm/cma: silence warnings due to max() usage
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Rothwell, Andrew Morton,
Linus Torvalds
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Rothwell <sfr@canb.auug.org.au>
commit badbda53e505089062e194c614e6f23450bc98b2 upstream.
pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long, ...) when comparing it.
fixes these warnings:
In file included from include/asm-generic/bug.h:13:0,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from include/linux/memblock.h:18,
from mm/cma.c:28:
mm/cma.c: In function 'cma_init_reserved_mem':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
mm/cma.c:186:27: note: in expansion of macro 'max'
alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
^
mm/cma.c: In function 'cma_declare_contiguous':
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
include/linux/kernel.h:747:9: note: in definition of macro 'max'
typeof(y) _max2 = (y); ^
mm/cma.c:270:29: note: in expansion of macro 'max'
(phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); ^
include/linux/kernel.h:747:21: note: in definition of macro 'max'
typeof(y) _max2 = (y); ^
mm/cma.c:270:29: note: in expansion of macro 'max'
(phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
^
[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20160526150748.5be38a4f@canb.auug.org.au
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/cma.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -183,7 +183,8 @@ int __init cma_init_reserved_mem(phys_ad
return -EINVAL;
/* ensure minimal alignment required by mm core */
- alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+ alignment = PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order);
/* alignment should be aligned with order_per_bit */
if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit))
@@ -266,8 +267,8 @@ int __init cma_declare_contiguous(phys_a
* migratetype page by page allocator's buddy algorithm. In the case,
* you couldn't get a contiguous memory, which is not what we want.
*/
- alignment = max(alignment,
- (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
+ alignment = max(alignment, (phys_addr_t)PAGE_SIZE <<
+ max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit &= ~(alignment - 1);
^ permalink raw reply
* [PATCH 4.4 61/69] smc91x: avoid self-comparison warning
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, David S. Miller
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream.
The smc91x driver defines a macro that compares its argument to
itself, apparently to get a true result while using its argument
to avoid a warning about unused local variables.
Unfortunately, this triggers a warning with gcc-6, as the comparison
is obviously useless:
drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt':
drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always evaluates to true [-Werror=tautological-compare]
if (!smc_special_trylock(&lp->lock, flags)) {
This replaces the macro with another one that behaves similarly,
with a cast to (void) to ensure the argument is used, and using
a literal 'true' as its value.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/smsc/smc91x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -540,7 +540,7 @@ static inline void smc_rcv(struct net_d
#define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags)
#define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags)
#else
-#define smc_special_trylock(lock, flags) (flags == flags)
+#define smc_special_trylock(lock, flags) ((void)flags, true)
#define smc_special_lock(lock, flags) do { flags = 0; } while (0)
#define smc_special_unlock(lock, flags) do { flags = 0; } while (0)
#endif
^ permalink raw reply
* [PATCH 4.4 63/69] UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Richard Weinberger
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -513,10 +513,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
- add_aeb(ai, free, pnum, ec, 1);
- else
- add_aeb(ai, free, pnum, ec, 0);
+ scrub = 1;
+
+ add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);
^ permalink raw reply
* [PATCH 4.4 40/69] dm mirror: fix read error on recovery after default leg failure
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Heinz Mauelshagen, Mike Snitzer
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heinz Mauelshagen <heinzm@redhat.com>
commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream.
If a default leg has failed, any read will cause a new operational
default leg to be selected and the read is resubmitted. But until now
the read will return failure even though it was successful due to
resubmission. The reason for this is bio->bi_error was not being
cleared before resubmitting the bio.
Fix by clearing bio->bi_error before resubmission.
Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-raid1.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -1288,6 +1288,7 @@ static int mirror_end_io(struct dm_targe
dm_bio_restore(bd, bio);
bio_record->details.bi_bdev = NULL;
+ bio->bi_error = 0;
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: liviu.dudau @ 2016-11-09 11:39 UTC (permalink / raw)
To: zhichang.yuan
Cc: catalin.marinas, will.deacon, robh+dt, bhelgaas, mark.rutland,
olof, arnd, linux-arm-kernel, lorenzo.pieralisi, linux-kernel,
linuxarm, devicetree, linux-pci, linux-serial, minyard, benh,
zourongrong, john.garry, gabriele.paoloni, zhichang.yuan02,
kantyzc, xuwei5
In-Reply-To: <1478576829-112707-3-git-send-email-yuanzhichang@hisilicon.com>
On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> This patch solves two issues:
> 1) parse and get the right I/O range from DTS node whose parent does not
> define the corresponding ranges property;
>
> There are some special ISA/LPC devices that work on a specific I/O range where
> it is not correct to specify a ranges property in DTS parent node as cpu
> addresses translated from DTS node are only for memory space on some
> architectures, such as Arm64. Without the parent 'ranges' property, current
> of_translate_address() return an error.
> Here we add a fixup function, of_get_isa_indirect_io(). During the OF address
> translation, this fixup will be called to check the 'reg' address to be
> translating is for those sepcial ISA/LPC devices and get the I/O range
> directly from the 'reg' property.
>
> 2) eliminate the I/O range conflict risk with PCI/PCIE leagecy I/O device;
>
> The current __of_address_to_resource() always translates the I/O range to PIO.
> But this processing is not suitable for our ISA/LPC devices whose I/O range is
> not cpu address(Arnd had stressed this in his comments on V2,V3 patch-set).
> Here, we bypass the mapping between cpu address and PIO for the special
> ISA/LPC devices. But to drive these ISA/LPC devices, a I/O port address below
> PCIBIOS_MIN_IO is needed by in*/out*(). Which means there is conflict risk
> between I/O range of [0, PCIBIOS_MIN_IO) and PCI/PCIE legacy I/O range of [0,
> IO_SPACE_LIMIT).
> To avoid the I/O conflict, this patch reserve the I/O range below
> PCIBIOS_MIN_IO.
>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 31 ++++++++++++
> arch/arm64/include/asm/io.h | 6 +++
> arch/arm64/kernel/extio.c | 25 ++++++++++
> drivers/of/address.c | 56 +++++++++++++++++++++-
> drivers/pci/pci.c | 6 +--
> include/linux/of_address.h | 17 +++++++
> include/linux/pci.h | 8 ++++
> 7 files changed, 145 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 0000000..13c8ddd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> + Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> + locate on LPC bus can be accessed direclty. But some SoCs have independent
> + LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> + Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> + The node name before '@' must be "isa" to represent the binding stick to the
> + ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b0000 {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b0000 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};
This documentation file needs to be part of the next patch. It has nothing to do with
what you are trying to fix here.
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 136735d..c26b7cc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -175,6 +175,12 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> #define outsl outsl
>
> DECLARE_EXTIO(l, u32)
> +
> +#define indirect_io_enabled indirect_io_enabled
> +extern bool indirect_io_enabled(void);
> +
> +#define addr_is_indirect_io addr_is_indirect_io
> +extern int addr_is_indirect_io(u64 taddr);
> #endif
>
>
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> index 647b3fa..3d45fa8 100644
> --- a/arch/arm64/kernel/extio.c
> +++ b/arch/arm64/kernel/extio.c
> @@ -19,6 +19,31 @@
>
> struct extio_ops *arm64_extio_ops;
>
> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + * arm64_extio_ops will be set only when indirectIO mechanism had been
> + * initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> + return arm64_extio_ops ? true : false;
> +}
> +
> +/**
> + * addr_is_indirect_io - check whether the input taddr is for indirectIO.
> + * @taddr: the io address to be checked.
> + *
> + * Returns 1 when taddr is in the range; otherwise return 0.
> + */
> +int addr_is_indirect_io(u64 taddr)
> +{
> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
start >= taddr ?
> + return 0;
> +
> + return 1;
> +}
>
> BUILD_EXTIO(b, u8)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..cc2a05d 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct device_node *np)
> return false;
> }
>
> +
> +/*
> + * of_isa_indirect_io - get the IO address from some isa reg property value.
> + * For some isa/lpc devices, no ranges property in ancestor node.
> + * The device addresses are described directly in their regs property.
> + * This fixup function will be called to get the IO address of isa/lpc
> + * devices when the normal of_translation failed.
> + *
> + * @parent: points to the parent dts node;
> + * @bus: points to the of_bus which can be used to parse address;
> + * @addr: the address from reg property;
> + * @na: the address cell counter of @addr;
> + * @presult: store the address paresed from @addr;
> + *
> + * return 1 when successfully get the I/O address;
> + * 0 will return for some failures.
Bah, you are returning a signed int, why 0 for failure? Return a negative value with
error codes. Otherwise change the return value into a bool.
> + */
> +static int of_get_isa_indirect_io(struct device_node *parent,
> + struct of_bus *bus, __be32 *addr,
> + int na, u64 *presult)
> +{
> + unsigned int flags;
> + unsigned int rlen;
> +
> + /* whether support indirectIO */
> + if (!indirect_io_enabled())
> + return 0;
> +
> + if (!of_bus_isa_match(parent))
> + return 0;
> +
> + flags = bus->get_flags(addr);
> + if (!(flags & IORESOURCE_IO))
> + return 0;
> +
> + /* there is ranges property, apply the normal translation directly. */
s/there is ranges/if we have a 'ranges'/
> + if (of_get_property(parent, "ranges", &rlen))
> + return 0;
> +
> + *presult = of_read_number(addr + 1, na - 1);
> + /* this fixup is only valid for specific I/O range. */
> + return addr_is_indirect_io(*presult);
> +}
> +
> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> struct of_bus *pbus, __be32 *addr,
> int na, int ns, int pna, const char *rprop)
> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct device_node *dev,
> result = of_read_number(addr, na);
> break;
> }
> + /*
> + * For indirectIO device which has no ranges property, get
> + * the address from reg directly.
> + */
> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
> + pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
> + of_node_full_name(dev), result);
> + break;
> + }
>
> /* Get new parent bus and counts */
> pbus = of_match_bus(parent);
> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct device_node *dev,
> if (taddr == OF_BAD_ADDR)
> return -EINVAL;
> memset(r, 0, sizeof(struct resource));
> - if (flags & IORESOURCE_IO) {
> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> unsigned long port;
> +
> port = pci_address_to_pio(taddr);
> if (port == (unsigned long)-1)
> return -EINVAL;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ba34907..1a08511 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>
> /* check if the range hasn't been previously recorded */
> spin_lock(&io_range_lock);
> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
Have you checked that pci_pio_to_address still returns valid values after this? I know that
you are trying to take into account PCIBIOS_MIN_IO limit when allocating reserving the IO ranges,
but the values added in the io_range_list are still starting from zero, no from PCIBIOS_MIN_IO,
so the calculation of the address in this function could return negative values casted to pci_addr_t.
Maybe you want to adjust the range->start value in pci_register_io_range() as well to have it
offset by PCIBIOS_MIN_IO as well.
Best regards,
Liviu
>
> if (pio > IO_SPACE_LIMIT)
> return address;
> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef PCI_IOBASE
> struct io_range *res;
> - resource_size_t offset = 0;
> + resource_size_t offset = PCIBIOS_MIN_IO;
> unsigned long addr = -1;
>
> spin_lock(&io_range_lock);
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 3786473..deec469 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -24,6 +24,23 @@ struct of_pci_range {
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
> +
> +#ifndef indirect_io_enabled
> +#define indirect_io_enabled indirect_io_enabled
> +static inline bool indirect_io_enabled(void)
> +{
> + return false;
> +}
> +#endif
> +
> +#ifndef addr_is_indirect_io
> +#define addr_is_indirect_io addr_is_indirect_io
> +static inline int addr_is_indirect_io(u64 taddr)
> +{
> + return 0;
> +}
> +#endif
> +
> /* Translate a DMA address from device space to CPU space */
> extern u64 of_translate_dma_address(struct device_node *dev,
> const __be32 *in_addr);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0e49f70..7f6bbb6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct pci_bus *bus)
> /* provide the legacy pci_dma_* API */
> #include <linux/pci-dma-compat.h>
>
> +/*
> + * define this macro here to refrain from compilation error for some
> + * platforms. Please keep this macro at the end of this header file.
> + */
> +#ifndef PCIBIOS_MIN_IO
> +#define PCIBIOS_MIN_IO 0
> +#endif
> +
> #endif /* LINUX_PCI_H */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: liviu.dudau at arm.com @ 2016-11-09 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478576829-112707-3-git-send-email-yuanzhichang@hisilicon.com>
On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> This patch solves two issues:
> 1) parse and get the right I/O range from DTS node whose parent does not
> define the corresponding ranges property;
>
> There are some special ISA/LPC devices that work on a specific I/O range where
> it is not correct to specify a ranges property in DTS parent node as cpu
> addresses translated from DTS node are only for memory space on some
> architectures, such as Arm64. Without the parent 'ranges' property, current
> of_translate_address() return an error.
> Here we add a fixup function, of_get_isa_indirect_io(). During the OF address
> translation, this fixup will be called to check the 'reg' address to be
> translating is for those sepcial ISA/LPC devices and get the I/O range
> directly from the 'reg' property.
>
> 2) eliminate the I/O range conflict risk with PCI/PCIE leagecy I/O device;
>
> The current __of_address_to_resource() always translates the I/O range to PIO.
> But this processing is not suitable for our ISA/LPC devices whose I/O range is
> not cpu address(Arnd had stressed this in his comments on V2,V3 patch-set).
> Here, we bypass the mapping between cpu address and PIO for the special
> ISA/LPC devices. But to drive these ISA/LPC devices, a I/O port address below
> PCIBIOS_MIN_IO is needed by in*/out*(). Which means there is conflict risk
> between I/O range of [0, PCIBIOS_MIN_IO) and PCI/PCIE legacy I/O range of [0,
> IO_SPACE_LIMIT).
> To avoid the I/O conflict, this patch reserve the I/O range below
> PCIBIOS_MIN_IO.
>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 31 ++++++++++++
> arch/arm64/include/asm/io.h | 6 +++
> arch/arm64/kernel/extio.c | 25 ++++++++++
> drivers/of/address.c | 56 +++++++++++++++++++++-
> drivers/pci/pci.c | 6 +--
> include/linux/of_address.h | 17 +++++++
> include/linux/pci.h | 8 ++++
> 7 files changed, 145 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 0000000..13c8ddd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> + Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> + locate on LPC bus can be accessed direclty. But some SoCs have independent
> + LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> + Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> + The node name before '@' must be "isa" to represent the binding stick to the
> + ISA/EISA binding specification.
> +
> +Example:
> +
> +isa at a01b0000 {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b0000 0x0 0x1000>;
> +
> + ipmi0: bt at e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};
This documentation file needs to be part of the next patch. It has nothing to do with
what you are trying to fix here.
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 136735d..c26b7cc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -175,6 +175,12 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> #define outsl outsl
>
> DECLARE_EXTIO(l, u32)
> +
> +#define indirect_io_enabled indirect_io_enabled
> +extern bool indirect_io_enabled(void);
> +
> +#define addr_is_indirect_io addr_is_indirect_io
> +extern int addr_is_indirect_io(u64 taddr);
> #endif
>
>
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> index 647b3fa..3d45fa8 100644
> --- a/arch/arm64/kernel/extio.c
> +++ b/arch/arm64/kernel/extio.c
> @@ -19,6 +19,31 @@
>
> struct extio_ops *arm64_extio_ops;
>
> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + * arm64_extio_ops will be set only when indirectIO mechanism had been
> + * initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> + return arm64_extio_ops ? true : false;
> +}
> +
> +/**
> + * addr_is_indirect_io - check whether the input taddr is for indirectIO.
> + * @taddr: the io address to be checked.
> + *
> + * Returns 1 when taddr is in the range; otherwise return 0.
> + */
> +int addr_is_indirect_io(u64 taddr)
> +{
> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
start >= taddr ?
> + return 0;
> +
> + return 1;
> +}
>
> BUILD_EXTIO(b, u8)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..cc2a05d 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct device_node *np)
> return false;
> }
>
> +
> +/*
> + * of_isa_indirect_io - get the IO address from some isa reg property value.
> + * For some isa/lpc devices, no ranges property in ancestor node.
> + * The device addresses are described directly in their regs property.
> + * This fixup function will be called to get the IO address of isa/lpc
> + * devices when the normal of_translation failed.
> + *
> + * @parent: points to the parent dts node;
> + * @bus: points to the of_bus which can be used to parse address;
> + * @addr: the address from reg property;
> + * @na: the address cell counter of @addr;
> + * @presult: store the address paresed from @addr;
> + *
> + * return 1 when successfully get the I/O address;
> + * 0 will return for some failures.
Bah, you are returning a signed int, why 0 for failure? Return a negative value with
error codes. Otherwise change the return value into a bool.
> + */
> +static int of_get_isa_indirect_io(struct device_node *parent,
> + struct of_bus *bus, __be32 *addr,
> + int na, u64 *presult)
> +{
> + unsigned int flags;
> + unsigned int rlen;
> +
> + /* whether support indirectIO */
> + if (!indirect_io_enabled())
> + return 0;
> +
> + if (!of_bus_isa_match(parent))
> + return 0;
> +
> + flags = bus->get_flags(addr);
> + if (!(flags & IORESOURCE_IO))
> + return 0;
> +
> + /* there is ranges property, apply the normal translation directly. */
s/there is ranges/if we have a 'ranges'/
> + if (of_get_property(parent, "ranges", &rlen))
> + return 0;
> +
> + *presult = of_read_number(addr + 1, na - 1);
> + /* this fixup is only valid for specific I/O range. */
> + return addr_is_indirect_io(*presult);
> +}
> +
> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> struct of_bus *pbus, __be32 *addr,
> int na, int ns, int pna, const char *rprop)
> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct device_node *dev,
> result = of_read_number(addr, na);
> break;
> }
> + /*
> + * For indirectIO device which has no ranges property, get
> + * the address from reg directly.
> + */
> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
> + pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
> + of_node_full_name(dev), result);
> + break;
> + }
>
> /* Get new parent bus and counts */
> pbus = of_match_bus(parent);
> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct device_node *dev,
> if (taddr == OF_BAD_ADDR)
> return -EINVAL;
> memset(r, 0, sizeof(struct resource));
> - if (flags & IORESOURCE_IO) {
> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> unsigned long port;
> +
> port = pci_address_to_pio(taddr);
> if (port == (unsigned long)-1)
> return -EINVAL;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ba34907..1a08511 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>
> /* check if the range hasn't been previously recorded */
> spin_lock(&io_range_lock);
> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
Have you checked that pci_pio_to_address still returns valid values after this? I know that
you are trying to take into account PCIBIOS_MIN_IO limit when allocating reserving the IO ranges,
but the values added in the io_range_list are still starting from zero, no from PCIBIOS_MIN_IO,
so the calculation of the address in this function could return negative values casted to pci_addr_t.
Maybe you want to adjust the range->start value in pci_register_io_range() as well to have it
offset by PCIBIOS_MIN_IO as well.
Best regards,
Liviu
>
> if (pio > IO_SPACE_LIMIT)
> return address;
> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef PCI_IOBASE
> struct io_range *res;
> - resource_size_t offset = 0;
> + resource_size_t offset = PCIBIOS_MIN_IO;
> unsigned long addr = -1;
>
> spin_lock(&io_range_lock);
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 3786473..deec469 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -24,6 +24,23 @@ struct of_pci_range {
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
> +
> +#ifndef indirect_io_enabled
> +#define indirect_io_enabled indirect_io_enabled
> +static inline bool indirect_io_enabled(void)
> +{
> + return false;
> +}
> +#endif
> +
> +#ifndef addr_is_indirect_io
> +#define addr_is_indirect_io addr_is_indirect_io
> +static inline int addr_is_indirect_io(u64 taddr)
> +{
> + return 0;
> +}
> +#endif
> +
> /* Translate a DMA address from device space to CPU space */
> extern u64 of_translate_dma_address(struct device_node *dev,
> const __be32 *in_addr);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0e49f70..7f6bbb6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct pci_bus *bus)
> /* provide the legacy pci_dma_* API */
> #include <linux/pci-dma-compat.h>
>
> +/*
> + * define this macro here to refrain from compilation error for some
> + * platforms. Please keep this macro at the end of this header file.
> + */
> +#ifndef PCIBIOS_MIN_IO
> +#define PCIBIOS_MIN_IO 0
> +#endif
> +
> #endif /* LINUX_PCI_H */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: liviu.dudau-5wv7dgnIgG8 @ 2016-11-09 11:39 UTC (permalink / raw)
To: zhichang.yuan
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
mark.rutland-5wv7dgnIgG8, olof-nZhT3qVonbNeoWH0uzbU5w,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <1478576829-112707-3-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> This patch solves two issues:
> 1) parse and get the right I/O range from DTS node whose parent does not
> define the corresponding ranges property;
>
> There are some special ISA/LPC devices that work on a specific I/O range where
> it is not correct to specify a ranges property in DTS parent node as cpu
> addresses translated from DTS node are only for memory space on some
> architectures, such as Arm64. Without the parent 'ranges' property, current
> of_translate_address() return an error.
> Here we add a fixup function, of_get_isa_indirect_io(). During the OF address
> translation, this fixup will be called to check the 'reg' address to be
> translating is for those sepcial ISA/LPC devices and get the I/O range
> directly from the 'reg' property.
>
> 2) eliminate the I/O range conflict risk with PCI/PCIE leagecy I/O device;
>
> The current __of_address_to_resource() always translates the I/O range to PIO.
> But this processing is not suitable for our ISA/LPC devices whose I/O range is
> not cpu address(Arnd had stressed this in his comments on V2,V3 patch-set).
> Here, we bypass the mapping between cpu address and PIO for the special
> ISA/LPC devices. But to drive these ISA/LPC devices, a I/O port address below
> PCIBIOS_MIN_IO is needed by in*/out*(). Which means there is conflict risk
> between I/O range of [0, PCIBIOS_MIN_IO) and PCI/PCIE legacy I/O range of [0,
> IO_SPACE_LIMIT).
> To avoid the I/O conflict, this patch reserve the I/O range below
> PCIBIOS_MIN_IO.
>
> Signed-off-by: zhichang.yuan <yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 31 ++++++++++++
> arch/arm64/include/asm/io.h | 6 +++
> arch/arm64/kernel/extio.c | 25 ++++++++++
> drivers/of/address.c | 56 +++++++++++++++++++++-
> drivers/pci/pci.c | 6 +--
> include/linux/of_address.h | 17 +++++++
> include/linux/pci.h | 8 ++++
> 7 files changed, 145 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 0000000..13c8ddd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> + Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> + locate on LPC bus can be accessed direclty. But some SoCs have independent
> + LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> + Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set of this device is mapped.
> +
> +Note:
> + The node name before '@' must be "isa" to represent the binding stick to the
> + ISA/EISA binding specification.
> +
> +Example:
> +
> +isa@a01b0000 {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b0000 0x0 0x1000>;
> +
> + ipmi0: bt@e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};
This documentation file needs to be part of the next patch. It has nothing to do with
what you are trying to fix here.
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 136735d..c26b7cc 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -175,6 +175,12 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> #define outsl outsl
>
> DECLARE_EXTIO(l, u32)
> +
> +#define indirect_io_enabled indirect_io_enabled
> +extern bool indirect_io_enabled(void);
> +
> +#define addr_is_indirect_io addr_is_indirect_io
> +extern int addr_is_indirect_io(u64 taddr);
> #endif
>
>
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> index 647b3fa..3d45fa8 100644
> --- a/arch/arm64/kernel/extio.c
> +++ b/arch/arm64/kernel/extio.c
> @@ -19,6 +19,31 @@
>
> struct extio_ops *arm64_extio_ops;
>
> +/**
> + * indirect_io_enabled - check whether indirectIO is enabled.
> + * arm64_extio_ops will be set only when indirectIO mechanism had been
> + * initialized.
> + *
> + * Returns true when indirectIO is enabled.
> + */
> +bool indirect_io_enabled(void)
> +{
> + return arm64_extio_ops ? true : false;
> +}
> +
> +/**
> + * addr_is_indirect_io - check whether the input taddr is for indirectIO.
> + * @taddr: the io address to be checked.
> + *
> + * Returns 1 when taddr is in the range; otherwise return 0.
> + */
> +int addr_is_indirect_io(u64 taddr)
> +{
> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
start >= taddr ?
> + return 0;
> +
> + return 1;
> +}
>
> BUILD_EXTIO(b, u8)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..cc2a05d 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct device_node *np)
> return false;
> }
>
> +
> +/*
> + * of_isa_indirect_io - get the IO address from some isa reg property value.
> + * For some isa/lpc devices, no ranges property in ancestor node.
> + * The device addresses are described directly in their regs property.
> + * This fixup function will be called to get the IO address of isa/lpc
> + * devices when the normal of_translation failed.
> + *
> + * @parent: points to the parent dts node;
> + * @bus: points to the of_bus which can be used to parse address;
> + * @addr: the address from reg property;
> + * @na: the address cell counter of @addr;
> + * @presult: store the address paresed from @addr;
> + *
> + * return 1 when successfully get the I/O address;
> + * 0 will return for some failures.
Bah, you are returning a signed int, why 0 for failure? Return a negative value with
error codes. Otherwise change the return value into a bool.
> + */
> +static int of_get_isa_indirect_io(struct device_node *parent,
> + struct of_bus *bus, __be32 *addr,
> + int na, u64 *presult)
> +{
> + unsigned int flags;
> + unsigned int rlen;
> +
> + /* whether support indirectIO */
> + if (!indirect_io_enabled())
> + return 0;
> +
> + if (!of_bus_isa_match(parent))
> + return 0;
> +
> + flags = bus->get_flags(addr);
> + if (!(flags & IORESOURCE_IO))
> + return 0;
> +
> + /* there is ranges property, apply the normal translation directly. */
s/there is ranges/if we have a 'ranges'/
> + if (of_get_property(parent, "ranges", &rlen))
> + return 0;
> +
> + *presult = of_read_number(addr + 1, na - 1);
> + /* this fixup is only valid for specific I/O range. */
> + return addr_is_indirect_io(*presult);
> +}
> +
> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> struct of_bus *pbus, __be32 *addr,
> int na, int ns, int pna, const char *rprop)
> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct device_node *dev,
> result = of_read_number(addr, na);
> break;
> }
> + /*
> + * For indirectIO device which has no ranges property, get
> + * the address from reg directly.
> + */
> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
> + pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
> + of_node_full_name(dev), result);
> + break;
> + }
>
> /* Get new parent bus and counts */
> pbus = of_match_bus(parent);
> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct device_node *dev,
> if (taddr == OF_BAD_ADDR)
> return -EINVAL;
> memset(r, 0, sizeof(struct resource));
> - if (flags & IORESOURCE_IO) {
> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> unsigned long port;
> +
> port = pci_address_to_pio(taddr);
> if (port == (unsigned long)-1)
> return -EINVAL;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ba34907..1a08511 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>
> /* check if the range hasn't been previously recorded */
> spin_lock(&io_range_lock);
> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
> #ifdef PCI_IOBASE
> struct io_range *range;
> - resource_size_t allocated_size = 0;
> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
Have you checked that pci_pio_to_address still returns valid values after this? I know that
you are trying to take into account PCIBIOS_MIN_IO limit when allocating reserving the IO ranges,
but the values added in the io_range_list are still starting from zero, no from PCIBIOS_MIN_IO,
so the calculation of the address in this function could return negative values casted to pci_addr_t.
Maybe you want to adjust the range->start value in pci_register_io_range() as well to have it
offset by PCIBIOS_MIN_IO as well.
Best regards,
Liviu
>
> if (pio > IO_SPACE_LIMIT)
> return address;
> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef PCI_IOBASE
> struct io_range *res;
> - resource_size_t offset = 0;
> + resource_size_t offset = PCIBIOS_MIN_IO;
> unsigned long addr = -1;
>
> spin_lock(&io_range_lock);
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 3786473..deec469 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -24,6 +24,23 @@ struct of_pci_range {
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
> +
> +#ifndef indirect_io_enabled
> +#define indirect_io_enabled indirect_io_enabled
> +static inline bool indirect_io_enabled(void)
> +{
> + return false;
> +}
> +#endif
> +
> +#ifndef addr_is_indirect_io
> +#define addr_is_indirect_io addr_is_indirect_io
> +static inline int addr_is_indirect_io(u64 taddr)
> +{
> + return 0;
> +}
> +#endif
> +
> /* Translate a DMA address from device space to CPU space */
> extern u64 of_translate_dma_address(struct device_node *dev,
> const __be32 *in_addr);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0e49f70..7f6bbb6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct pci_bus *bus)
> /* provide the legacy pci_dma_* API */
> #include <linux/pci-dma-compat.h>
>
> +/*
> + * define this macro here to refrain from compilation error for some
> + * platforms. Please keep this macro at the end of this header file.
> + */
> +#ifndef PCIBIOS_MIN_IO
> +#define PCIBIOS_MIN_IO 0
> +#endif
> +
> #endif /* LINUX_PCI_H */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH 4.4 41/69] Input: i8042 - add XMG C504 to keyboard reset table
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Patrick Scheuring, Dmitry Torokhov
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.
The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.
With this patch the touchpad is detected:
$ dmesg | grep -E "(i8042|Elantech|elantech)"
[ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[ 2.680372] i8042: Attempting to reset device connected to KBD port
[ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
[ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
Signed-off-by: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
},
},
+ {
+ /* Schenker XMG C504 - Elantech touchpad */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+ },
+ },
{ }
};
^ permalink raw reply
* [PATCH 4.4 43/69] firewire: net: fix fragmented datagram_size off-by-one
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stefan Richter
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firewire/net.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,13 +73,13 @@ struct rfc2734_header {
#define fwnet_get_hdr_lf(h) (((h)->w0 & 0xc0000000) >> 30)
#define fwnet_get_hdr_ether_type(h) (((h)->w0 & 0x0000ffff))
-#define fwnet_get_hdr_dg_size(h) (((h)->w0 & 0x0fff0000) >> 16)
+#define fwnet_get_hdr_dg_size(h) ((((h)->w0 & 0x0fff0000) >> 16) + 1)
#define fwnet_get_hdr_fg_off(h) (((h)->w0 & 0x00000fff))
#define fwnet_get_hdr_dgl(h) (((h)->w1 & 0xffff0000) >> 16)
-#define fwnet_set_hdr_lf(lf) ((lf) << 30)
+#define fwnet_set_hdr_lf(lf) ((lf) << 30)
#define fwnet_set_hdr_ether_type(et) (et)
-#define fwnet_set_hdr_dg_size(dgs) ((dgs) << 16)
+#define fwnet_set_hdr_dg_size(dgs) (((dgs) - 1) << 16)
#define fwnet_set_hdr_fg_off(fgo) (fgo)
#define fwnet_set_hdr_dgl(dgl) ((dgl) << 16)
@@ -622,7 +622,7 @@ static int fwnet_incoming_packet(struct
fg_off = fwnet_get_hdr_fg_off(&hdr);
}
datagram_label = fwnet_get_hdr_dgl(&hdr);
- dg_size = fwnet_get_hdr_dg_size(&hdr); /* ??? + 1 */
+ dg_size = fwnet_get_hdr_dg_size(&hdr);
if (fg_off + len > dg_size)
return 0;
^ permalink raw reply
* [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Sahu @ 2016-11-09 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476962064-8775-1-git-send-email-rsahu@apm.com>
Hi Olof/Tejun,
On Thu, Oct 20, 2016 at 4:44 PM, Rameshwar Prasad Sahu <rsahu@apm.com> wrote:
>
> This patch enables NCQ support for APM X-Gene SATA controller
> hardware v1.1 that was broken with hardware v1.0.
>
> Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
> ---
> drivers/ata/ahci_xgene.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 73b19b2..8b88be9 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -87,6 +87,7 @@
>
> enum xgene_ahci_version {
> XGENE_AHCI_V1 = 1,
> + XGENE_AHCI_V1_1,
> XGENE_AHCI_V2,
> };
>
> @@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id xgene_ahci_acpi_match[] = {
> { "APMC0D0D", XGENE_AHCI_V1},
> + { "APMC0D67", XGENE_AHCI_V1_1},
> { "APMC0D32", XGENE_AHCI_V2},
> {},
> };
> @@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
>
> static const struct of_device_id xgene_ahci_of_match[] = {
> {.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
> + {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
> {.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
> {},
> };
> @@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> struct resource *res;
> const struct of_device_id *of_devid;
> enum xgene_ahci_version version = XGENE_AHCI_V1;
> - const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
> - &xgene_ahci_v2_port_info };
> + const struct ata_port_info *ppi;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
> __func__);
> version = XGENE_AHCI_V1;
> - } else if (info->valid & ACPI_VALID_CID) {
> - version = XGENE_AHCI_V2;
> }
> }
> }
> @@ -858,18 +858,20 @@ skip_clk_phy:
>
> switch (version) {
> case XGENE_AHCI_V1:
> + ppi = &xgene_ahci_v1_port_info;
> hpriv->flags = AHCI_HFLAG_NO_NCQ;
> break;
> case XGENE_AHCI_V2:
> + ppi = &xgene_ahci_v2_port_info;
> hpriv->flags |= AHCI_HFLAG_YES_FBS;
> hpriv->irq_handler = xgene_ahci_irq_intr;
> break;
> default:
> + ppi = &xgene_ahci_v1_port_info;
> break;
> }
>
> - rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
> - &ahci_platform_sht);
> + rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
> if (rc)
> goto disable_resources;
>
> --
> 1.7.1
Any comment on above patch ??
^ permalink raw reply
* Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Sahu @ 2016-11-09 11:39 UTC (permalink / raw)
To: Olof Johansson, tj, Arnd Bergmann
Cc: Devicetree List, mlangsdo, linux-scsi, Jon Masters,
Rameshwar Prasad Sahu, patches, linux-ide, linux-arm
In-Reply-To: <1476962064-8775-1-git-send-email-rsahu@apm.com>
Hi Olof/Tejun,
On Thu, Oct 20, 2016 at 4:44 PM, Rameshwar Prasad Sahu <rsahu@apm.com> wrote:
>
> This patch enables NCQ support for APM X-Gene SATA controller
> hardware v1.1 that was broken with hardware v1.0.
>
> Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
> ---
> drivers/ata/ahci_xgene.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 73b19b2..8b88be9 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -87,6 +87,7 @@
>
> enum xgene_ahci_version {
> XGENE_AHCI_V1 = 1,
> + XGENE_AHCI_V1_1,
> XGENE_AHCI_V2,
> };
>
> @@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id xgene_ahci_acpi_match[] = {
> { "APMC0D0D", XGENE_AHCI_V1},
> + { "APMC0D67", XGENE_AHCI_V1_1},
> { "APMC0D32", XGENE_AHCI_V2},
> {},
> };
> @@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
>
> static const struct of_device_id xgene_ahci_of_match[] = {
> {.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
> + {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
> {.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
> {},
> };
> @@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> struct resource *res;
> const struct of_device_id *of_devid;
> enum xgene_ahci_version version = XGENE_AHCI_V1;
> - const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
> - &xgene_ahci_v2_port_info };
> + const struct ata_port_info *ppi;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
> __func__);
> version = XGENE_AHCI_V1;
> - } else if (info->valid & ACPI_VALID_CID) {
> - version = XGENE_AHCI_V2;
> }
> }
> }
> @@ -858,18 +858,20 @@ skip_clk_phy:
>
> switch (version) {
> case XGENE_AHCI_V1:
> + ppi = &xgene_ahci_v1_port_info;
> hpriv->flags = AHCI_HFLAG_NO_NCQ;
> break;
> case XGENE_AHCI_V2:
> + ppi = &xgene_ahci_v2_port_info;
> hpriv->flags |= AHCI_HFLAG_YES_FBS;
> hpriv->irq_handler = xgene_ahci_irq_intr;
> break;
> default:
> + ppi = &xgene_ahci_v1_port_info;
> break;
> }
>
> - rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
> - &ahci_platform_sht);
> + rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
> if (rc)
> goto disable_resources;
>
> --
> 1.7.1
Any comment on above patch ??
^ permalink raw reply
* [PATCH 4.4 44/69] mac80211: discard multicast and 4-addr A-MSDUs
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.
In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
* drop A-MSDUs with a multicast A1 (RA), as required by the
spec in 9.11 (802.11-2012 version)
* drop A-MSDUs with a 4-addr header, since the fourth address
can't actually be useful for them; unless 4-address frame
format is actually requested, even though the fourth address
is still not useful in this case, but ignored
Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/rx.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2203,16 +2203,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
if (!(status->rx_flags & IEEE80211_RX_AMSDU))
return RX_CONTINUE;
- if (ieee80211_has_a4(hdr->frame_control) &&
- rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- !rx->sdata->u.vlan.sta)
- return RX_DROP_UNUSABLE;
+ if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+ switch (rx->sdata->vif.type) {
+ case NL80211_IFTYPE_AP_VLAN:
+ if (!rx->sdata->u.vlan.sta)
+ return RX_DROP_UNUSABLE;
+ break;
+ case NL80211_IFTYPE_STATION:
+ if (!rx->sdata->u.mgd.use_4addr)
+ return RX_DROP_UNUSABLE;
+ break;
+ default:
+ return RX_DROP_UNUSABLE;
+ }
+ }
- if (is_multicast_ether_addr(hdr->addr1) &&
- ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- rx->sdata->u.vlan.sta) ||
- (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- rx->sdata->u.mgd.use_4addr)))
+ if (is_multicast_ether_addr(hdr->addr1))
return RX_DROP_UNUSABLE;
skb->dev = dev;
^ permalink raw reply
* [PATCH 4.4 45/69] scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kashyap Desai, Sumit Saxena,
Tomas Henzl, Hannes Reinecke, Ewan D. Milne, Martin K. Petersen
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kashyap Desai <kashyap.desai@broadcom.com>
commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1688,16 +1688,13 @@ megasas_queue_command(struct Scsi_Host *
goto out_done;
}
- switch (scmd->cmnd[0]) {
- case SYNCHRONIZE_CACHE:
- /*
- * FW takes care of flush cache on its own
- * No need to send it down
- */
+ /*
+ * FW takes care of flush cache on its own for Virtual Disk.
+ * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to FW.
+ */
+ if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
- default:
- break;
}
if (instance->instancet->build_and_issue_cmd(instance, scmd)) {
^ permalink raw reply
* [PATCH 4.4 69/69] HID: usbhid: add ATEN CS962 to list of quirky devices
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Oliver Neukum, Jiri Kosina
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <oneukum@suse.com>
commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -168,6 +168,7 @@
#define USB_DEVICE_ID_ATEN_4PORTKVM 0x2205
#define USB_DEVICE_ID_ATEN_4PORTKVMC 0x2208
#define USB_DEVICE_ID_ATEN_CS682 0x2213
+#define USB_DEVICE_ID_ATEN_CS692 0x8021
#define USB_VENDOR_ID_ATMEL 0x03eb
#define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -61,6 +61,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, HID_QUIRK_NOGET },
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Daniel P. Berrange @ 2016-11-09 11:37 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Andrew Jones, Dave Young, qiaonuohan, bhe, anderson, qemu-devel
In-Reply-To: <9144d6b1-a1c9-e727-4673-9df10b227fdb@redhat.com>
On Wed, Nov 09, 2016 at 12:26:17PM +0100, Laszlo Ersek wrote:
> On 11/09/16 11:40, Andrew Jones wrote:
> > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote:
> >> Hi,
> >>
> >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> >> addresses, we had some effort to support kexec/kdump so that crash
> >> utility can still works in case crashed kernel has kaslr enabled.
> >>
> >> But according to Dave Anderson virsh dump does not work, quoted messages
> >> from Dave below:
> >>
> >> """
> >> with virsh dump, there's no way of even knowing that KASLR
> >> has randomized the kernel __START_KERNEL_map region, because there is no
> >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> >> vmcoreinfo data to compare against the vmlinux file symbol value.
> >> Unless virsh dump can export some basic virtual memory data, which
> >> they say it can't, I don't see how KASLR can ever be supported.
> >> """
> >>
> >> I assume virsh dump is using qemu guest memory dump facility so it
> >> should be first addressed in qemu. Thus post this query to qemu devel
> >> list. If this is not correct please let me know.
> >>
> >> Could you qemu dump people make it work? Or we can not support virt dump
> >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
> >>
> >
> > When the -kernel command line option is used, then it may be possible
> > to extract some information that could be used to supplement the memory
> > dump that dump-guest-memory provides. However, that would be a specific
> > use. In general, QEMU knows nothing about the guest kernel. It doesn't
> > know where it is in the disk image, and it doesn't even know if it's
> > Linux.
> >
> > Is there anything a guest userspace application could probe from e.g.
> > /proc that would work? If so, then the guest agent could gain a new
> > feature providing that.
>
> I fully agree. This is exactly what I suggested too, independently, in
> the downstream thread, before arriving at this upstream thread. Let me
> quote that email:
>
> On 11/09/16 12:09, Laszlo Ersek wrote:
> > [...] the dump-guest-memory QEMU command supports an option called
> > "paging". Here's its documentation, from the "qapi-schema.json" source
> > file:
> >
> >> # @paging: if true, do paging to get guest's memory mapping. This allows
> >> # using gdb to process the core file.
> >> #
> >> # IMPORTANT: this option can make QEMU allocate several gigabytes
> >> # of RAM. This can happen for a large guest, or a
> >> # malicious guest pretending to be large.
> >> #
> >> # Also, paging=true has the following limitations:
> >> #
> >> # 1. The guest may be in a catastrophic state or can have corrupted
> >> # memory, which cannot be trusted
> >> # 2. The guest can be in real-mode even if paging is enabled. For
> >> # example, the guest uses ACPI to sleep, and ACPI sleep state
> >> # goes in real-mode
> >> # 3. Currently only supported on i386 and x86_64.
> >> #
> >
> > "virsh dump --memory-only" sets paging=false, for obvious reasons.
> >
> > [...] the dump-guest-memory command provides a raw snapshot of the
> > virtual machine's memory (and of the registers of the VCPUs); it is
> > not enlightened about the guest.
> >
> > If the additional information you are looking for can be retrieved
> > within the running Linux guest, using an appropriately privieleged
> > userspace process, then I would recommend considering an extension to
> > the qemu guest agent. The management layer (libvirt, [...]) could
> > first invoke the guest agent (a process with root privileges running
> > in the guest) from the host side, through virtio-serial. The new guest
> > agent command would return the information necessary to deal with
> > KASLR. Then the management layer would initiate the dump like always.
> > Finally, the extra information would be combined with (or placed
> > beside) the dump file in some way.
> >
> > So, this proposal would affect the guest agent and the management
> > layer (= libvirt).
>
> Given that we already dislike "paging=true", enlightening
> dump-guest-memory with even more guest-specific insight is the wrong
> approach, IMO. That kind of knowledge belongs to the guest agent.
If you're trying to debug a hung/panicked guest, then using a guest
agent to fetch info is a complete non-starter as it'll be dead.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* [PATCH 4.8 011/138] gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen, Linus Walleij
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream.
The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.
Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.
Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio
u32 lflags = handlereq.flags;
struct gpio_desc *desc;
+ if (offset >= gdev->ngpio) {
+ ret = -EINVAL;
+ goto out_free_descs;
+ }
+
desc = &gdev->descs[offset];
ret = gpiod_request(desc, lh->label);
if (ret)
^ permalink raw reply
* [srcu] Can we suppress sparse warning?
From: Tetsuo Handa @ 2016-11-09 11:36 UTC (permalink / raw)
To: paulmck, josh; +Cc: rostedt, mathieu.desnoyers, jiangshanlai, linux-kernel
Hello.
When I build
---------- test/test.c ----------
#include <linux/module.h>
static int __init test_init(void)
{
DEFINE_SRCU(srcu);
int idx = srcu_read_lock(&srcu);
void *ptr = srcu_dereference(ptr, &srcu);
srcu_read_unlock(&srcu, idx);
return -EINVAL;
}
module_init(test_init);
MODULE_LICENSE("GPL");
---------- test/test.c ----------
with C=1 option, I get
test/test.c:7:21: error: incompatible types in comparison expression (different address spaces)
warning from
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -605,7 +605,7 @@ static inline void rcu_preempt_sleep_check(void)
/* Dependency order vs. p above. */ \
typeof(*p) *________p1 = (typeof(*p) *__force)lockless_dereference(p); \
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_check() usage"); \
- rcu_dereference_sparse(p, space); \
+ rcu_dereference_sparse(p, space); /** this line **/ \
((typeof(*p) __force __kernel *)(________p1)); \
})
#define __rcu_dereference_protected(p, c, space) \
.
I want to use srcu_dereference() at
https://lists.01.org/pipermail/kbuild-all/2016-October/026587.html .
Can we have srcu version of 995f1405610bd844 ("rcu: Suppress sparse
warnings for rcu_dereference_raw()") ?
Regards.
^ permalink raw reply
* [PATCH 4.8 013/138] gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen, Linus Walleij
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit b8b0e3d303654b3bb7b31b0266c513fd6f4132ce upstream.
The line offset that is used as an index into the descs array is provided
by userspace and might go beyond the bounds of the array. If that happens
undefined behavior will occur.
Make sure that the offset is within the bounds of the desc array and reject
any requests that specify a value outside of it.
Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -731,6 +731,11 @@ static int lineevent_create(struct gpio_
lflags = eventreq.handleflags;
eflags = eventreq.eventflags;
+ if (offset >= gdev->ngpio) {
+ ret = -EINVAL;
+ goto out_free_label;
+ }
+
/* This is just wrong: we don't look for events on output lines */
if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
ret = -EINVAL;
^ permalink raw reply
* Re: CPUID improvements (phase 2) Design Doc
From: Andrew Cooper @ 2016-11-09 11:36 UTC (permalink / raw)
To: Jan Beulich
Cc: Lan Tianyu, Wei Liu, IanJackson, Xen-devel, Joao Martins,
Roger Pau Monne
In-Reply-To: <5822ED0E020000780011D458@prv-mh.provo.novell.com>
On 09/11/16 08:31, Jan Beulich wrote:
>>>> On 08.11.16 at 19:36, <andrew.cooper3@citrix.com> wrote:
>> On 08/11/16 16:32, Jan Beulich wrote:
>>>>>> On 08.11.16 at 16:35, <andrew.cooper3@citrix.com> wrote:
>>>> Please find inline the design doc for further CPUID improvements, planned for
>>>> development during the 4.9 timeframe.
>>> Looks good, just a couple of minor remarks.
>>>
>>>> ## Changes in hypercall behaviour
>>>>
>>>> During domain construction, some pieces of information critical to the
>>>> determination of the domains maximum acceptable CPUID policy are available
>>>> right from the very start (Most notably, the HVM and HAP flags from the
>>>> `XEN_DOMCTL_createdomain`).
>>>>
>>>> However, some other parameters are not available at convenient points.
>>>>
>>>> 1. The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>>>> `d->disable_migrate`, whose only purpose is to avoid the unconditional
>>>> clobbering of the Invariant TSC flag. This flag cannot even be queried by
>>>> the toolstack once set.
>>>>
>>>> There are other facilities which should be restricted based on whether a
>>>> VM might migrate or not. (e.g. The use of LBR, whose record format is
>>>> hardware specific.)
>>> Not really - the LBR format only limits the set of hosts the VM can
>>> migrate to. I.e. this is just like a CPUID flag which needs to be set
>>> on the target host in order for the VM to be permitted to migrate
>>> there.
>> It is more complicated than that. The LBR format also depends on
>> whether TSX is enabled or not, which on Haswell-WS CPUs depends on
>> whether hyperthreading is enabled.
> Yes, but is this relevant? It's still only a value (identifying the format)
> which needs to match between source and destination hosts. I.e. not
> different from individual feature bits, just that here we're dealing with
> a multi-bit entity.
LBR format is controlled by IA32_PERF_CAPABILITIES[5:0], which I will
eventually get to covering with MSR levelling, with this being a
strictly non-levelable field.
Users' expectations when migrating a VM is that it should be able to go
anywhere. In practice, this is only insofar as we can maintain
compatibility. We should default to being as compatible as possible; if
a user asks for both migrateable and LBR, then thats fine as it comes
with an understanding of reduced mobility.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 4.8 015/138] gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen, Linus Walleij
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit ac7dbb991ee5afc0beacce3a252dcaaa249a7786 upstream.
The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined
linehandle and lineevent flags. From a backwards and forwards compatibility
viewpoint it is highly desirable to reject unknown flags though.
On one hand an application that is using newer flags and is running on
an older kernel has no way to detect if the new flags were handled
correctly if they are silently discarded.
On the other hand an application that (accidentally) passes undefined flags
will run fine on an older kernel, but may break on a newer kernel when
these flags get defined.
Ensure that requests that have undefined flags set are rejected with an
error, rather than silently discarding the undefined flags.
Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -554,6 +554,10 @@ struct lineevent_state {
struct mutex read_lock;
};
+#define GPIOEVENT_REQUEST_VALID_FLAGS \
+ (GPIOEVENT_REQUEST_RISING_EDGE | \
+ GPIOEVENT_REQUEST_FALLING_EDGE)
+
static unsigned int lineevent_poll(struct file *filep,
struct poll_table_struct *wait)
{
@@ -748,6 +752,13 @@ static int lineevent_create(struct gpio_
ret = -EINVAL;
goto out_free_label;
}
+
+ /* Return an error if a unknown flag is set */
+ if ((lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) ||
+ (eflags & ~GPIOEVENT_REQUEST_VALID_FLAGS)) {
+ ret = -EINVAL;
+ goto out_free_label;
+ }
/* This is just wrong: we don't look for events on output lines */
if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
^ permalink raw reply
* [PATCH 4.8 017/138] gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen, Linus Walleij
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit 953b956a2e6d35298e684f251bad98ea6c96f982 upstream.
When allocating a new line handle or event a file is allocated that it is
associated to. The file is attached to a file descriptor of the current
process and the file descriptor is returned to userspace using
copy_to_user(). If this copy operation fails the line handle or event
allocation is aborted, all acquired resources are freed and an error is
returned.
But the file struct is not freed and left attached to the userspace
application and even though the file descriptor number was not copied it is
trivial to guess. If a userspace application performs a IOCTL on such a
left over file descriptor it will trigger a use-after-free and if the file
descriptor is closed (latest when the application exits) a double-free is
triggered.
anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
file descriptor for the current process and install the file struct in the
file descriptor. As soon as the file struct is installed in the file
descriptor it is accessible by userspace (even if the IOCTL itself hasn't
completed yet), this means uninstalling the fd on the error path is not an
option, since userspace might already got a reference to the file.
Instead anon_inode_getfd() needs to be broken into its individual steps.
The allocation of the file struct and file descriptor is done first, then
the copy_to_user() is executed and only if it succeeds the file is
installed.
Since the file struct is reference counted it can not be just freed, but
its reference needs to be dropped, which will also call the release()
callback, which will free the state attached to the file. So in this case
the normal error cleanup path should not be taken.
Fixes: d932cd49182f ("gpio: free handles in fringe cases")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 57 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 45 insertions(+), 12 deletions(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -21,6 +21,7 @@
#include <linux/uaccess.h>
#include <linux/compat.h>
#include <linux/anon_inodes.h>
+#include <linux/file.h>
#include <linux/kfifo.h>
#include <linux/poll.h>
#include <linux/timekeeping.h>
@@ -421,6 +422,7 @@ static int linehandle_create(struct gpio
{
struct gpiohandle_request handlereq;
struct linehandle_state *lh;
+ struct file *file;
int fd, i, ret;
if (copy_from_user(&handlereq, ip, sizeof(handlereq)))
@@ -497,26 +499,41 @@ static int linehandle_create(struct gpio
i--;
lh->numdescs = handlereq.lines;
- fd = anon_inode_getfd("gpio-linehandle",
- &linehandle_fileops,
- lh,
- O_RDONLY | O_CLOEXEC);
+ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
if (fd < 0) {
ret = fd;
goto out_free_descs;
}
+ file = anon_inode_getfile("gpio-linehandle",
+ &linehandle_fileops,
+ lh,
+ O_RDONLY | O_CLOEXEC);
+ if (IS_ERR(file)) {
+ ret = PTR_ERR(file);
+ goto out_put_unused_fd;
+ }
+
handlereq.fd = fd;
if (copy_to_user(ip, &handlereq, sizeof(handlereq))) {
- ret = -EFAULT;
- goto out_free_descs;
+ /*
+ * fput() will trigger the release() callback, so do not go onto
+ * the regular error cleanup path here.
+ */
+ fput(file);
+ put_unused_fd(fd);
+ return -EFAULT;
}
+ fd_install(fd, file);
+
dev_dbg(&gdev->dev, "registered chardev handle for %d lines\n",
lh->numdescs);
return 0;
+out_put_unused_fd:
+ put_unused_fd(fd);
out_free_descs:
for (; i >= 0; i--)
gpiod_free(lh->descs[i]);
@@ -719,6 +736,7 @@ static int lineevent_create(struct gpio_
struct gpioevent_request eventreq;
struct lineevent_state *le;
struct gpio_desc *desc;
+ struct file *file;
u32 offset;
u32 lflags;
u32 eflags;
@@ -813,23 +831,38 @@ static int lineevent_create(struct gpio_
if (ret)
goto out_free_desc;
- fd = anon_inode_getfd("gpio-event",
- &lineevent_fileops,
- le,
- O_RDONLY | O_CLOEXEC);
+ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
if (fd < 0) {
ret = fd;
goto out_free_irq;
}
+ file = anon_inode_getfile("gpio-event",
+ &lineevent_fileops,
+ le,
+ O_RDONLY | O_CLOEXEC);
+ if (IS_ERR(file)) {
+ ret = PTR_ERR(file);
+ goto out_put_unused_fd;
+ }
+
eventreq.fd = fd;
if (copy_to_user(ip, &eventreq, sizeof(eventreq))) {
- ret = -EFAULT;
- goto out_free_irq;
+ /*
+ * fput() will trigger the release() callback, so do not go onto
+ * the regular error cleanup path here.
+ */
+ fput(file);
+ put_unused_fd(fd);
+ return -EFAULT;
}
+ fd_install(fd, file);
+
return 0;
+out_put_unused_fd:
+ put_unused_fd(fd);
out_free_irq:
free_irq(le->irq, le);
out_free_desc:
^ permalink raw reply
* [PATCH 4.8 019/138] mm/list_lru.c: avoid error-path NULL pointer deref
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Polakov, Vladimir Davydov,
Al Viro, Andrew Morton, Linus Torvalds
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Polakov <apolyakov@beget.ru>
commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream.
As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821:
After some analysis it seems to be that the problem is in alloc_super().
In case list_lru_init_memcg() fails it goes into destroy_super(), which
calls list_lru_destroy().
And in list_lru_init() we see that in case memcg_init_list_lru() fails,
lru->node is freed, but not set NULL, which then leads list_lru_destroy()
to believe it is initialized and call memcg_destroy_list_lru().
memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus,
which is NULL.
[akpm@linux-foundation.org: add comment]
Signed-off-by: Alexander Polakov <apolyakov@beget.ru>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/list_lru.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -554,6 +554,8 @@ int __list_lru_init(struct list_lru *lru
err = memcg_init_list_lru(lru, memcg_aware);
if (err) {
kfree(lru->node);
+ /* Do this so a list_lru_destroy() doesn't crash: */
+ lru->node = NULL;
goto out;
}
^ permalink raw reply
* Re: [PATCH] kernel.bbclass: Allow ${S} to be overridden
From: Burton, Ross @ 2016-11-09 11:34 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: OpenEmbedded Core
In-Reply-To: <CAJTo0LZxGYzpjUetPspX6mKktoL_XnDqfncyHFWN5Kzfij8-UQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On 9 November 2016 at 10:04, Burton, Ross <ross.burton@intel.com> wrote:
> Saying that of course doomed the patch:
>
Double doomed, perf can't build either.
ERROR: perf-1.0-r9 do_configure: Function failed: do_configure (log file is
located at
/data/poky-master/tmp-glibc/work/intel_corei7_64-poky-linux/perf/1.0-r9/temp/log.do_configure.23322)
ERROR: Logfile of failure stored in:
/data/poky-master/tmp-glibc/work/intel_corei7_64-poky-linux/perf/1.0-r9/temp/log.do_configure.23322
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| sed: can't read
/data/poky-master/tmp-glibc/work-shared/intel-corei7-64/kernel-source/tools/perf/Makefile*:
No such file or directory
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_configure (log file is located at
/data/poky-master/tmp-glibc/work/intel_corei7_64-poky-linux/perf/1.0-r9/temp/log.do_configure.23322)
Ross
[-- Attachment #2: Type: text/html, Size: 1800 bytes --]
^ 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.