* Re: [PATCH v6 4/6] lib/dlock-list: Make sibling CPUs share the same linked list
From: Jan Kara @ 2017-10-05 8:59 UTC (permalink / raw)
To: Waiman Long
Cc: Alexander Viro, Jan Kara, Jeff Layton, J. Bruce Fields, Tejun Heo,
Christoph Lameter, linux-fsdevel, linux-kernel, Ingo Molnar,
Peter Zijlstra, Andi Kleen, Dave Chinner, Boqun Feng,
Davidlohr Bueso, Waiman Long
In-Reply-To: <1507152007-28753-5-git-send-email-longman@redhat.com>
On Wed 04-10-17 17:20:05, Waiman Long wrote:
> int alloc_dlock_list_heads(struct dlock_list_heads *dlist)
> {
> - int idx;
> + int idx, cnt = nr_dlock_lists ? nr_dlock_lists : nr_cpu_ids;
Hum, is this there for the case where alloc_dlock_list_heads() is called
before nr_dlock_lists is initialized? But how can the dlist be used later
when it has larger number of lists and you don't know how many?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v4 00/14] Introduce support for Dell SMBIOS over WMI
From: Andy Shevchenko @ 2017-10-05 9:00 UTC (permalink / raw)
To: Darren Hart
Cc: Mario Limonciello, LKML, Platform Driver, Andy Lutomirski,
quasisec, Pali Rohár, Rafael J. Wysocki, mjg59,
Christoph Hellwig, Greg KH
In-Reply-To: <20171005000936.GB25018@fury>
On Thu, Oct 5, 2017 at 3:09 AM, Darren Hart <dvhart@infradead.org> wrote:
> On Wed, Oct 04, 2017 at 05:48:26PM -0500, Mario Limonciello wrote:
>>
>> NOTE: This patch is intended to go on top of the 6 patches already in
>> Darren's review tree.
>
> I pushed these to for-next today, they should be available in linux-next
> shortly.
Not before beginning of November.
P.S. This month no linux-next.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] seabios: uri corrected to https
From: Dariusz Pelowski @ 2017-10-05 9:00 UTC (permalink / raw)
To: meta-virtualization
There's a problem with fetching SeaBIOS source code via http.
SeaBIOS server returns 308: Permanent Redirect which fails on
wget 1.17.1. The official source code uri goes to https, this
patch aligns SRC_URI to officialy provided by SeaBIOS team.
Signed-off-by: Dariusz Pelowski <dariusz.pelowski@gmail.com>
---
recipes-extended/seabios/seabios_1.9.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-extended/seabios/seabios_1.9.1.bb b/recipes-extended/seabios/seabios_1.9.1.bb
index 5c095ac..144b13c 100644
--- a/recipes-extended/seabios/seabios_1.9.1.bb
+++ b/recipes-extended/seabios/seabios_1.9.1.bb
@@ -4,7 +4,7 @@ LICENSE = "LGPLv3"
SECTION = "firmware"
SRC_URI = " \
- http://code.coreboot.org/p/seabios/downloads/get/${PN}-${PV}.tar.gz \
+ https://code.coreboot.org/p/seabios/downloads/get/${PN}-${PV}.tar.gz \
file://hostcc.patch \
"
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device
From: Thomas Huth @ 2017-10-05 9:00 UTC (permalink / raw)
To: Igor Mammedov, Eduardo Habkost
Cc: Paolo Bonzini, qemu-devel, Markus Armbruster,
Dr. David Alan Gilbert
In-Reply-To: <20171005103629.156e9a9b@nial.brq.redhat.com>
On 05.10.2017 10:36, Igor Mammedov wrote:
> On Tue, 3 Oct 2017 15:49:46 -0300
> Eduardo Habkost <ehabkost@redhat.com> wrote:
>
>> On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote:
>>> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
>>> so QEMU crashes when the user tries to device_add + device_del a device
>>> that does not have a corresponding hotplug controller. This could be
>>> provoked for a couple of devices in the past (see commit 4c93950659487c7ad
>>> or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
>>> controller when they are suitable for device_add.
>>> The code in qdev_device_add() already checks whether the bus has a proper
>>> hotplug controller, but for devices that do not have a corresponding bus,
>>> there is no appropriate check available. In that case we should check
>>> whether the machine itself provides a suitable hotplug controller and
>>> refuse to plug the device if none is available.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> This is the follow-up patch from my earlier try "hw/core/qdev: Do not
>>> allow hot-plugging without hotplug controller" ... AFAICS the function
>>> qdev_device_add() is now the right spot to do the check.
>>>
>>> hw/core/qdev.c | 28 ++++++++++++++++++++--------
>>> include/hw/qdev-core.h | 1 +
>>> qdev-monitor.c | 9 +++++++++
>>> 3 files changed, 30 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>>> index 606ab53..a953ec9 100644
>>> --- a/hw/core/qdev.c
>>> +++ b/hw/core/qdev.c
>>> @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
>>> dev->alias_required_for_version = required_for_version;
>>> }
>>>
>>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
>>> +{
>>> + MachineState *machine;
>>> + MachineClass *mc;
>>> + Object *m_obj = qdev_get_machine();
>>> +
>>> + if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
>>> + machine = MACHINE(m_obj);
>>> + mc = MACHINE_GET_CLASS(machine);
>>> + if (mc->get_hotplug_handler) {
>>> + return mc->get_hotplug_handler(machine, dev);
>>> + }
>>> + }
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
>>> {
>>> - HotplugHandler *hotplug_ctrl = NULL;
>>> + HotplugHandler *hotplug_ctrl;
>>>
>>> if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
>>> hotplug_ctrl = dev->parent_bus->hotplug_handler;
>>> - } else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
>>> - MachineState *machine = MACHINE(qdev_get_machine());
>>> - MachineClass *mc = MACHINE_GET_CLASS(machine);
>>> -
>>> - if (mc->get_hotplug_handler) {
>>> - hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
>>> - }
>>> + } else {
>>> + hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
>>> }
>>> return hotplug_ctrl;
>>> }
>>> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
>>> index 0891461..5aa536d 100644
>>> --- a/include/hw/qdev-core.h
>>> +++ b/include/hw/qdev-core.h
>>> @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char *name);
>>> void qdev_init_nofail(DeviceState *dev);
>>> void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
>>> int required_for_version);
>>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
>>> HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
>>> void qdev_unplug(DeviceState *dev, Error **errp);
>>> void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
>>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>>> index 8fd6df9..2891dde 100644
>>> --- a/qdev-monitor.c
>>> +++ b/qdev-monitor.c
>>> @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
>>> return NULL;
>>> }
>>>
>>> + /* In case we don't have a bus, there must be a machine hotplug handler */
>>> + if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
>>> + error_setg(errp, "Device '%s' can not be hotplugged on this machine",
>>> + driver);
>>> + object_unparent(OBJECT(dev));
>>
>> Isn't it better to check qdev_get_machine_hotplug_handler()
>> earlier (before the qdev_set_parent_bus() and qdev_set_id()
>> lines), so object_unparent() isn't necessary?
>>
>> (We probably don't need to call object_unparent() here, already,
>> because bus is NULL. But moving the check before the "if (bus)
>> qdev_set_parent_bus()" statement would make this more obvious).
> it might be bus or bus-less device, so making check before
> qdev_set_parent_bus() should be simpler.
The check for devices that have a bus is already done earlier in this
function ("if (qdev_hotplug && bus && !qbus_is_hotpluggable(bus))") ...
but yes, I'll move the new check for bus-less devices a little bit
earlier so that the unparent is not necessary anymore.
>> I would prefer to eventually make
>> MachineClass::get_hotplug_handler() get a typename or
>> DeviceClass* argument instead of DeviceState*, so we don't even
>> create the device object. But I don't think it's a requirement
>> for this bug fix.
> choice of hotplug handler might theoretically depend on plugged
> device instance (over-engineered? as far as I recall none does it so far)
Yes, currently we might be able to do it with the typename only ... but
that seems to be a rather big rework right now, and we might indeed need
a real device instance later again, so I'd prefer to rather not do that
rework right now.
>>> + object_unref(OBJECT(dev));
>>> + return NULL;
>>> + }
> wrt error exit path, I'd rework error path in qdev_device_add() in separate patch first
> to look like it is in device_set_realized() and then just jump to appropriate label
> from here.
Ok, I can have a try whether that looks better.
Thomas
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] hw/s390x: Mark the "sclpquiesce" device with user_creatable = false
From: Halil Pasic @ 2017-10-05 9:00 UTC (permalink / raw)
To: Thomas Huth, qemu-devel, Cornelia Huck, Christian Borntraeger
Cc: Eric Farman, Janosch Frank, Yi Min Zhao, Jason J Herne,
David Hildenbrand, Pierre Morel, Farhan Ali, Jing Liu,
Claudio Imbrenda, QingFeng Hao, Xiao Feng Ren, Fei Li,
Dong Jia Shi, Yang Chen
In-Reply-To: <1507193105-15627-1-git-send-email-thuth@redhat.com>
On 10/05/2017 10:45 AM, Thomas Huth wrote:
> The "sclpquiesce" device is just an internal device that should not be
> created by the user directly. Though it currently does not seem to cause
> any obvious trouble when the user instantiates an additional device, let's
> better mark it with user_creatable = false to avoid unexpected behavior,
> e.g. because the quiesce notifier gets registered multiple times.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
> ---
> hw/s390x/sclpquiesce.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/hw/s390x/sclpquiesce.c b/hw/s390x/sclpquiesce.c
> index 762cb18..0241643 100644
> --- a/hw/s390x/sclpquiesce.c
> +++ b/hw/s390x/sclpquiesce.c
> @@ -118,8 +118,13 @@ static void quiesce_class_init(ObjectClass *klass, void *data)
> dc->reset = quiesce_reset;
> dc->vmsd = &vmstate_sclpquiesce;
> set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> - k->init = quiesce_init;
> + /*
> + * Reason: This is just an internal device - the notifier should
> + * not be registered multiple times in quiesce_init()
> + */
> + dc->user_creatable = false;
>
> + k->init = quiesce_init;
> k->get_send_mask = send_mask;
> k->get_receive_mask = receive_mask;
> k->can_handle_event = can_handle_event;
>
^ permalink raw reply
* Re: [PATCH v2 06/13] fuzz/x86_emulate: Rename the file containing the wrapper code
From: Jan Beulich @ 2017-10-05 9:01 UTC (permalink / raw)
To: George Dunlap; +Cc: Andrew Cooper, Wei Liu, xen-devel, Ian Jackson
In-Reply-To: <2c264867-03cf-b905-f7a3-03092de8f95b@citrix.com>
>>> On 04.10.17 at 18:34, <george.dunlap@citrix.com> wrote:
> On 10/04/2017 09:23 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, <george.dunlap@citrix.com> wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/Makefile
>>> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
>>> @@ -18,22 +18,22 @@ asm:
>>>
>>> asm/%: asm ;
>>>
>>> -x86_emulate.c x86_emulate.h: %:
>>> +x86_emulate_user.c x86_emulate_user.h: %:
>>
>> How about avoiding the names getting even longer? E.g. using
>> x86-emulate.[ch] or x86emul-user.[ch] instead?
>
> My original idea was to make it easy to construct the original filename
> from the long filename. I don't have super-strong opinions (mostly
> because I think all the options I've seen are pretty bad), but I still
> think that this is the least-bad option.
>
> If you have strong opinions about one of the other ones, let me know and
> I'll change it.
Well, together with the suggested alternatives being shorter,
they also slightly improve word completion behavior when typing
in partial file names, so yes, I'd really appreciate renaming them
(and I've listed the suggestions above in the order of my
preference).
>>> @@ -42,7 +42,7 @@ all: x86-insn-fuzz-all
>>>
>>> .PHONY: distclean
>>> distclean: clean
>>> - rm -f x86_emulate x86_emulate.c x86_emulate.h asm
>>> + rm -f x86_emulate x86_emulate_user.c x86_emulate_user.h asm
>>
>> If you want to stick to the longer names, would you mind taking the
>> opportunity to make this just x86_emulate* ?
>
> What if you put something in that directly called
> "x86_emulate_user.c.diff" (or something like that) and then ran "make
> clean"?
>
> I tend to think that 'make clean' should only clean things that it is
> pretty confident were put there by the build system, and not the user.
Ah, yes, I see your point, albeit I don't fully agree: I would
actually prefer "make clean" to leave a clean tree, not one
with user created files left in. But indeed that's a matter of
taste.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Patch "ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: afzal.mohd.ma, alexander.levin, gregkh, rmk+kernel,
vladimir.murzin
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8635-1-nommu-allow-enabling-remap_vectors_to_ram.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Date: Sat, 7 Jan 2017 17:48:10 +0100
Subject: ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
[ Upstream commit 8a792e9afbce84a0fdaf213fe42bb97382487094 ]
REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
available to Kconfig, DRAM_BASE also is available as the Kconfig
gets sourced on !MMU.
Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/Kconfig-nommu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -34,8 +34,7 @@ config PROCESSOR_ID
used instead of the auto-probing which utilizes the register.
config REMAP_VECTORS_TO_RAM
- bool 'Install vectors to the beginning of RAM' if DRAM_BASE
- depends on DRAM_BASE
+ bool 'Install vectors to the beginning of RAM'
help
The kernel needs to change the hardware exception vectors.
In nommu mode, the hardware exception vectors are normally
Patches currently in stable-queue which might be from afzal.mohd.ma@gmail.com are
queue-3.18/arm-8635-1-nommu-allow-enabling-remap_vectors_to_ram.patch
^ permalink raw reply
* Re: API in dpdk to get total free physical memory
From: Burakov, Anatoly @ 2017-10-05 9:02 UTC (permalink / raw)
To: Venumadhav Josyula, dev@dpdk.org
In-Reply-To: <DM5PR19MB0939B3E0A850162BF173CFBCBF700@DM5PR19MB0939.namprd19.prod.outlook.com>
On 05-Oct-17 6:56 AM, Venumadhav Josyula wrote:
> Hi All,
>
> Like 'rte_eal_get_physmem_size' api to the total size of the physical memory. Is there an API to get to get total free memory physical memory available ?
>
> We want such API we are planning to implement such API for the same
>
> /* get the total size of memory */
> uint64_t
> rte_eal_get_physmem_free(int socket_id)
> {
> const struct rte_mem_config *mcfg;
> unsigned i = 0;
> uint64_t total_len = 0;
>
> /* get pointer to global configuration */
> mcfg = rte_eal_get_configuration()->mem_config;
>
> for (i=0; i<RTE_MAX_MEMSEG; i++) {
> if (mcfg->free_memseg[i].addr == NULL)
> break;
>
> if (mcfg->free_memseg[i].len == 0)
> continue;
>
> /* bad socket ID */
> if (socket_id != SOCKET_ID_ANY &&
> mcfg->free_memseg[i].socket_id != SOCKET_ID_ANY &&
> socket_id != mcfg->free_memseg[i].socket_id)
> continue;
>
> total_len += mcfg->free_memseg[i].len;
> }
>
> return total_len;
> }
>
> Thanks,
> Regards
> Venu
>
Hi Venu,
I don't think there is such an API, so you're welcome to submit a patch.
--
Thanks,
Anatoly
^ permalink raw reply
* Patch "audit: log 32-bit socketcalls" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: rgb, alexander.levin, davem, gregkh, paul; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
audit: log 32-bit socketcalls
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
audit-log-32-bit-socketcalls.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Richard Guy Briggs <rgb@redhat.com>
Date: Tue, 17 Jan 2017 11:07:15 -0500
Subject: audit: log 32-bit socketcalls
From: Richard Guy Briggs <rgb@redhat.com>
[ Upstream commit 62bc306e2083436675e33b5bdeb6a77907d35971 ]
32-bit socketcalls were not being logged by audit on x86_64 systems.
Log them. This is basically a duplicate of the call from
net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
between 32-bit userspace process and 64-bit kernel audit.
See: https://github.com/linux-audit/audit-kernel/issues/14
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/audit.h | 20 ++++++++++++++++++++
net/compat.c | 17 ++++++++++++++---
2 files changed, 34 insertions(+), 3 deletions(-)
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -273,6 +273,20 @@ static inline int audit_socketcall(int n
return __audit_socketcall(nargs, args);
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ unsigned long a[AUDITSC_ARGS];
+ int i;
+
+ if (audit_dummy_context())
+ return 0;
+
+ for (i = 0; i < nargs; i++)
+ a[i] = (unsigned long)args[i];
+ return __audit_socketcall(nargs, a);
+}
+
static inline int audit_sockaddr(int len, void *addr)
{
if (unlikely(!audit_dummy_context()))
@@ -398,6 +412,12 @@ static inline int audit_socketcall(int n
{
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ return 0;
+}
+
static inline void audit_fd_pair(int fd1, int fd2)
{ }
static inline int audit_sockaddr(int len, void *addr)
--- a/net/compat.c
+++ b/net/compat.c
@@ -22,6 +22,7 @@
#include <linux/filter.h>
#include <linux/compat.h>
#include <linux/security.h>
+#include <linux/audit.h>
#include <linux/export.h>
#include <net/scm.h>
@@ -796,14 +797,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd
COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
{
- int ret;
- u32 a[6];
+ u32 a[AUDITSC_ARGS];
+ unsigned int len;
u32 a0, a1;
+ int ret;
if (call < SYS_SOCKET || call > SYS_SENDMMSG)
return -EINVAL;
- if (copy_from_user(a, args, nas[call]))
+ len = nas[call];
+ if (len > sizeof(a))
+ return -EINVAL;
+
+ if (copy_from_user(a, args, len))
return -EFAULT;
+
+ ret = audit_socketcall_compat(len / sizeof(a[0]), a);
+ if (ret)
+ return ret;
+
a0 = a[0];
a1 = a[1];
Patches currently in stable-queue which might be from rgb@redhat.com are
queue-3.18/audit-log-32-bit-socketcalls.patch
^ permalink raw reply
* Patch "[media] exynos-gsc: Do not swap cb/cr for semi planar formats" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: thibault.saunier, alexander.levin, gregkh, javier, mchehab,
nicolas.dufresne, s.nawrocki
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] exynos-gsc: Do not swap cb/cr for semi planar formats
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
Date: Wed, 1 Feb 2017 18:05:21 -0200
Subject: [media] exynos-gsc: Do not swap cb/cr for semi planar formats
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
[ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ]
In the case of semi planar formats cb and cr are in the same plane
in memory, meaning that will be set to 'cb' whatever the format is,
and whatever the (packed) order of those components are.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -846,9 +846,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx
if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M))
swap(addr->cb, addr->cr);
Patches currently in stable-queue which might be from thibault.saunier@osg.samsung.com are
queue-3.18/exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
^ permalink raw reply
* [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
From: Geert Uytterhoeven @ 2017-10-05 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507193900-23801-3-git-send-email-jacopo+renesas@jmondi.org>
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> MTU2 multi-function/multi-channel timer/counter is not enabled for
> GR-Peach board. The timer is used as clock event source to schedule
> wake-ups, and without this enabled all sleeps not performed through busy
> waiting hang the board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Patch "hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: linux, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Guenter Roeck <linux@roeck-us.net>
Date: Tue, 27 Dec 2016 14:15:07 -0800
Subject: hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
written and the fan divider is larger than 1.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/gl520sm.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/drivers/hwmon/gl520sm.c
+++ b/drivers/hwmon/gl520sm.c
@@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device
}
static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL);
-#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4)
-#define VDD_TO_REG(val) clamp_val((((val) * 4 + 47) / 95), 0, 255)
-
-#define IN_FROM_REG(val) ((val) * 19)
-#define IN_TO_REG(val) clamp_val((((val) + 9) / 19), 0, 255)
+#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4)
+#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4)
+#define VDD_TO_REG(val) DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95)
+
+#define IN_FROM_REG(val) ((val) * 19)
+#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19)
+#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19)
static ssize_t get_in_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU
#define DIV_FROM_REG(val) (1 << (val))
#define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (480000 / ((val) << (div))))
-#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \
- clamp_val((480000 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255))
+
+#define FAN_BASE(div) (480000 >> (div))
+#define FAN_CLAMP(val, div) clamp_val(val, FAN_BASE(div) / 255, \
+ FAN_BASE(div))
+#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \
+ DIV_ROUND_CLOSEST(480000, \
+ FAN_CLAMP(val, div) << (div)))
static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR
static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR,
get_fan_off, set_fan_off);
-#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
-#define TEMP_TO_REG(val) clamp_val(((((val) < 0 ? \
- (val) - 500 : (val) + 500) / 1000) + 130), 0, 255)
+#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
+#define TEMP_CLAMP(val) clamp_val(val, -130000, 125000)
+#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130)
static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr,
char *buf)
Patches currently in stable-queue which might be from linux@roeck-us.net are
queue-3.18/hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.patch
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
From: Geert Uytterhoeven @ 2017-10-05 9:02 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1507193900-23801-3-git-send-email-jacopo+renesas@jmondi.org>
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> MTU2 multi-function/multi-channel timer/counter is not enabled for
> GR-Peach board. The timer is used as clock event source to schedule
> wake-ups, and without this enabled all sleeps not performed through busy
> waiting hang the board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Patch "drm: bridge: add DT bindings for TI ths8135" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: bgolaszewski, alexander.levin, architt, gregkh, laurent.pinchart,
robh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: bridge: add DT bindings for TI ths8135
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-bridge-add-dt-bindings-for-ti-ths8135.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date: Tue, 13 Dec 2016 11:09:16 +0100
Subject: drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
Patches currently in stable-queue which might be from bgolaszewski@baylibre.com are
queue-3.18/drm-bridge-add-dt-bindings-for-ti-ths8135.patch
^ permalink raw reply
* Patch "IB/ipoib: Fix deadlock over vlan_mutex" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix deadlock over vlan_mutex
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-fix-deadlock-over-vlan_mutex.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:22 +0200
Subject: IB/ipoib: Fix deadlock over vlan_mutex
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
This patch fixes Deadlock while executing ipoib_vlan_delete.
The function takes the vlan_rwsem semaphore and calls
unregister_netdevice. The later function calls
ipoib_mcast_stop_thread that cause workqueue flush.
When the queue has one of the ipoib_ib_dev_flush_xxx events,
a deadlock occur because these events also tries to catch the
same vlan_rwsem semaphore.
To fix, unregister_netdevice should be called after releasing
the semaphore.
Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child interface create")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -187,7 +187,6 @@ int ipoib_vlan_delete(struct net_device
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
if (priv->pkey == pkey &&
priv->child_type == IPOIB_LEGACY_CHILD) {
- unregister_netdevice(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
@@ -195,6 +194,11 @@ int ipoib_vlan_delete(struct net_device
}
up_write(&ppriv->vlan_rwsem);
+ if (dev) {
+ ipoib_dbg(ppriv, "delete child vlan %s\n", dev->name);
+ unregister_netdevice(dev);
+ }
+
rtnl_unlock();
if (dev) {
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-3.18/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-3.18/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-3.18/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/ipoib: rtnl_unlock can not come after free_netdev" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon,
ogerlitz, yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: rtnl_unlock can not come after free_netdev
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:24 +0200
Subject: IB/ipoib: rtnl_unlock can not come after free_netdev
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 89a3987ab7a923c047c6dec008e60ad6f41fac22 ]
The ipoib_vlan_add function calls rtnl_unlock after free_netdev,
rtnl_unlock not only releases the lock, but also calls netdev_run_todo.
The latter function browses the net_todo_list array and completes the
unregistration of all its net_device instances. If we call free_netdev
before rtnl_unlock, then netdev_run_todo call over the freed device causes
panic.
To fix, move rtnl_unlock call before free_netdev call.
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -162,11 +162,11 @@ int ipoib_vlan_add(struct net_device *pd
out:
up_write(&ppriv->vlan_rwsem);
+ rtnl_unlock();
+
if (result)
free_netdev(priv->dev);
- rtnl_unlock();
-
return result;
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-3.18/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-3.18/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-3.18/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/ipoib: Replace list_del of the neigh->list with list_del_init" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex,
yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Replace list_del of the neigh->list with list_del_init
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:27 +0200
Subject: IB/ipoib: Replace list_del of the neigh->list with list_del_init
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -958,7 +958,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1121,7 +1121,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1206,7 +1206,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1248,7 +1248,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-3.18/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-3.18/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-3.18/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "md/raid10: submit bio directly to replacement disk" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: shli, alexander.levin, gregkh, neilb; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
md/raid10: submit bio directly to replacement disk
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
md-raid10-submit-bio-directly-to-replacement-disk.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Shaohua Li <shli@fb.com>
Date: Thu, 23 Feb 2017 12:26:41 -0800
Subject: md/raid10: submit bio directly to replacement disk
From: Shaohua Li <shli@fb.com>
[ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
Commit 57c67df(md/raid10: submit IO from originating thread instead of
md thread) submits bio directly for normal disks but not for replacement
disks. There is no point we shouldn't do this for replacement disks.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid10.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1514,11 +1514,24 @@ retry_write:
mbio->bi_private = r10_bio;
atomic_inc(&r10_bio->remaining);
+
+ cb = blk_check_plugged(raid10_unplug, mddev,
+ sizeof(*plug));
+ if (cb)
+ plug = container_of(cb, struct raid10_plug_cb,
+ cb);
+ else
+ plug = NULL;
spin_lock_irqsave(&conf->device_lock, flags);
- bio_list_add(&conf->pending_bio_list, mbio);
- conf->pending_count++;
+ if (plug) {
+ bio_list_add(&plug->pending, mbio);
+ plug->pending_cnt++;
+ } else {
+ bio_list_add(&conf->pending_bio_list, mbio);
+ conf->pending_count++;
+ }
spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!mddev_check_plugged(mddev))
+ if (!plug)
md_wakeup_thread(mddev->thread);
}
}
Patches currently in stable-queue which might be from shli@fb.com are
queue-3.18/md-raid10-submit-bio-directly-to-replacement-disk.patch
^ permalink raw reply
* Patch "libata: transport: Remove circular dependency at free time" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: gwendal, alexander.levin, gregkh, tedheadster, tj; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
libata: transport: Remove circular dependency at free time
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
libata-transport-remove-circular-dependency-at-free-time.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Gwendal Grignou <gwendal@chromium.org>
Date: Fri, 3 Mar 2017 09:00:09 -0800
Subject: libata: transport: Remove circular dependency at free time
From: Gwendal Grignou <gwendal@chromium.org>
[ Upstream commit d85fc67dd11e9a32966140677d4d6429ca540b25 ]
Without this patch, failed probe would not free resources like irq.
ata port tdev object currently hold a reference to the ata port
object. Therefore the ata port object release function will not get
called until the ata_tport_release is called. But that would never
happen, releasing the last reference of ata port dev is done by
scsi_host_release, which is called by ata_host_release when the ata
port object is released.
The ata device objects actually do not need to explicitly hold a
reference to their real counterpart, given the transport objects are
the children of these objects and device_add() is call for each child.
We know the parent will not be deleted until we call the child's
device_del().
Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-transport.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -223,7 +223,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_
static void ata_tport_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -283,7 +282,7 @@ int ata_tport_add(struct device *parent,
device_initialize(dev);
dev->type = &ata_port_type;
- dev->parent = get_device(parent);
+ dev->parent = parent;
dev->release = ata_tport_release;
dev_set_name(dev, "ata%d", ap->print_id);
transport_setup_device(dev);
@@ -347,7 +346,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_
static void ata_tlink_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -409,7 +407,7 @@ int ata_tlink_add(struct ata_link *link)
int error;
device_initialize(dev);
- dev->parent = get_device(&ap->tdev);
+ dev->parent = &ap->tdev;
dev->release = ata_tlink_release;
if (ata_is_host_link(link))
dev_set_name(dev, "link%d", ap->print_id);
@@ -587,7 +585,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_c
static void ata_tdev_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -660,7 +657,7 @@ static int ata_tdev_add(struct ata_devic
int error;
device_initialize(dev);
- dev->parent = get_device(&link->tdev);
+ dev->parent = &link->tdev;
dev->release = ata_tdev_release;
if (ata_is_host_link(link))
dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
Patches currently in stable-queue which might be from gwendal@chromium.org are
queue-3.18/libata-transport-remove-circular-dependency-at-free-time.patch
^ permalink raw reply
* Patch "MIPS: kexec: Do not reserve invalid crashkernel memory on boot" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: marcin.nowakowski, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: kexec: Do not reserve invalid crashkernel memory on boot
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-kexec-do-not-reserve-invalid-crashkernel-memory-on-boot.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed, 23 Nov 2016 14:43:50 +0100
Subject: MIPS: kexec: Do not reserve invalid crashkernel memory on boot
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
[ Upstream commit a8f108d70c74d83574c157648383eb2e4285a190 ]
Do not reserve memory for the crashkernel if the commandline argument
points to a wrong location. This can happen if the location is specified
wrong or if the same commandline is reused when starting the crashkernel
- in the latter case the reserved memory would point to the location
from which the crashkernel is executing.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14612/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/setup.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -585,6 +585,11 @@ static void __init mips_parse_crashkerne
if (ret != 0 || crash_size <= 0)
return;
+ if (!memory_region_available(crash_base, crash_size)) {
+ pr_warn("Invalid memory region reserved for crash kernel\n");
+ return;
+ }
+
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
Patches currently in stable-queue which might be from marcin.nowakowski@imgtec.com are
queue-3.18/mips-kexec-do-not-reserve-invalid-crashkernel-memory-on-boot.patch
^ permalink raw reply
* Patch "MIPS: Ensure bss section ends on a long-aligned address" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: paul.burton, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: Ensure bss section ends on a long-aligned address
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-ensure-bss-section-ends-on-a-long-aligned-address.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Paul Burton <paul.burton@imgtec.com>
Date: Mon, 7 Nov 2016 11:52:19 +0000
Subject: MIPS: Ensure bss section ends on a long-aligned address
From: Paul Burton <paul.burton@imgtec.com>
[ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
When clearing the .bss section in kernel_entry we do so using LONG_S
instructions, and branch whilst the current write address doesn't equal
the end of the .bss section minus the size of a long integer. The .bss
section always begins at a long-aligned address and we always increment
the write pointer by the size of a long integer - we therefore rely upon
the .bss section ending at a long-aligned address. If this is not the
case then the long-aligned write address can never be equal to the
non-long-aligned end address & we will continue to increment past the
end of the .bss section, attempting to zero the rest of memory.
Despite this requirement that .bss end at a long-aligned address we pass
0 as the end alignment requirement to the BSS_SECTION macro and thus
don't guarantee any particular alignment, allowing us to hit the error
condition described above.
Fix this by instead passing 8 bytes as the end alignment argument to
the BSS_SECTION macro, ensuring that the end of the .bss section is
always at least long-aligned.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14526/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -141,7 +141,7 @@ SECTIONS
* Force .bss to 64K alignment so that .bss..swapper_pg_dir
* gets that alignment. .sbss should be empty, so there will be
* no holes after __init_end. */
- BSS_SECTION(0, 0x10000, 0)
+ BSS_SECTION(0, 0x10000, 8)
_end = . ;
Patches currently in stable-queue which might be from paul.burton@imgtec.com are
queue-3.18/mips-ensure-bss-section-ends-on-a-long-aligned-address.patch
^ permalink raw reply
* Patch "mmc: sdio: fix alignment issue in struct sdio_func" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: hkallweit1, alexander.levin, gregkh, hgkr.klein, ulf.hansson
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mmc: sdio: fix alignment issue in struct sdio_func
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mmc-sdio-fix-alignment-issue-in-struct-sdio_func.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 29 Mar 2017 20:54:37 +0200
Subject: mmc: sdio: fix alignment issue in struct sdio_func
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/sdio_bus.c | 12 +++++++++++-
include/linux/mmc/sdio_func.h | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -265,7 +265,7 @@ static void sdio_release_func(struct dev
sdio_free_func_cis(func);
kfree(func->info);
-
+ kfree(func->tmpbuf);
kfree(func);
}
@@ -280,6 +280,16 @@ struct sdio_func *sdio_alloc_func(struct
if (!func)
return ERR_PTR(-ENOMEM);
+ /*
+ * allocate buffer separately to make sure it's properly aligned for
+ * DMA usage (incl. 64 bit DMA)
+ */
+ func->tmpbuf = kmalloc(4, GFP_KERNEL);
+ if (!func->tmpbuf) {
+ kfree(func);
+ return ERR_PTR(-ENOMEM);
+ }
+
func->card = card;
device_initialize(&func->dev);
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -53,7 +53,7 @@ struct sdio_func {
unsigned int state; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
- u8 tmpbuf[4]; /* DMA:able scratch buffer */
+ u8 *tmpbuf; /* DMA:able scratch buffer */
unsigned num_info; /* number of info strings */
const char **info; /* info strings */
Patches currently in stable-queue which might be from hkallweit1@gmail.com are
queue-3.18/mmc-sdio-fix-alignment-issue-in-struct-sdio_func.patch
^ permalink raw reply
* Patch "net: core: Prevent from dereferencing null pointer when releasing SKB" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: mhjungk, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
net: core: Prevent from dereferencing null pointer when releasing SKB
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-core-prevent-from-dereferencing-null-pointer-when-releasing-skb.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Myungho Jung <mhjungk@gmail.com>
Date: Tue, 25 Apr 2017 11:58:15 -0700
Subject: net: core: Prevent from dereferencing null pointer when releasing SKB
From: Myungho Jung <mhjungk@gmail.com>
[ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2225,6 +2225,9 @@ void __dev_kfree_skb_irq(struct sk_buff
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
Patches currently in stable-queue which might be from mhjungk@gmail.com are
queue-3.18/net-core-prevent-from-dereferencing-null-pointer-when-releasing-skb.patch
^ permalink raw reply
* Patch "net/packet: check length in getsockopt() called with PACKET_HDRLEN" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: glider, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
net/packet: check length in getsockopt() called with PACKET_HDRLEN
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-packet-check-length-in-getsockopt-called-with-packet_hdrlen.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Alexander Potapenko <glider@google.com>
Date: Tue, 25 Apr 2017 18:51:46 +0200
Subject: net/packet: check length in getsockopt() called with PACKET_HDRLEN
From: Alexander Potapenko <glider@google.com>
[ Upstream commit fd2c83b35752f0a8236b976978ad4658df14a59f ]
In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
|val| remains uninitialized and the syscall may behave differently
depending on its value, and even copy garbage to userspace on certain
architectures. To fix this we now return -EINVAL if optlen is too small.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3482,6 +3482,8 @@ static int packet_getsockopt(struct sock
case PACKET_HDRLEN:
if (len > sizeof(int))
len = sizeof(int);
+ if (len < sizeof(int))
+ return -EINVAL;
if (copy_from_user(&val, optval, len))
return -EFAULT;
switch (val) {
Patches currently in stable-queue which might be from glider@google.com are
queue-3.18/net-packet-check-length-in-getsockopt-called-with-packet_hdrlen.patch
^ permalink raw reply
* Patch "netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: zlpnobody, alexander.levin, gregkh, pablo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
netfilter-nfnl_cthelper-fix-incorrect-helper-expect_class_max.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:58:04 CEST 2017
From: Liping Zhang <zlpnobody@gmail.com>
Date: Sun, 19 Mar 2017 22:35:59 +0800
Subject: netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max
From: Liping Zhang <zlpnobody@gmail.com>
[ Upstream commit ae5c682113f9f94cc5e76f92cf041ee624c173ee ]
The helper->expect_class_max must be set to the total number of
expect_policy minus 1, since we will use the statement "if (class >
helper->expect_class_max)" to validate the CTA_EXPECT_CLASS attr in
ctnetlink_alloc_expect.
So for compatibility, set the helper->expect_class_max to the
NFCTH_POLICY_SET_NUM attr's value minus 1.
Also: it's invalid when the NFCTH_POLICY_SET_NUM attr's value is zero.
1. this will result "expect_policy = kzalloc(0, GFP_KERNEL);";
2. we cannot set the helper->expect_class_max to a proper value.
So if nla_get_be32(tb[NFCTH_POLICY_SET_NUM]) is zero, report -EINVAL to
the userspace.
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/nfnetlink_cthelper.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -161,6 +161,7 @@ nfnl_cthelper_parse_expect_policy(struct
int i, ret;
struct nf_conntrack_expect_policy *expect_policy;
struct nlattr *tb[NFCTH_POLICY_SET_MAX+1];
+ unsigned int class_max;
ret = nla_parse_nested(tb, NFCTH_POLICY_SET_MAX, attr,
nfnl_cthelper_expect_policy_set);
@@ -170,19 +171,18 @@ nfnl_cthelper_parse_expect_policy(struct
if (!tb[NFCTH_POLICY_SET_NUM])
return -EINVAL;
- helper->expect_class_max =
- ntohl(nla_get_be32(tb[NFCTH_POLICY_SET_NUM]));
-
- if (helper->expect_class_max != 0 &&
- helper->expect_class_max > NF_CT_MAX_EXPECT_CLASSES)
+ class_max = ntohl(nla_get_be32(tb[NFCTH_POLICY_SET_NUM]));
+ if (class_max == 0)
+ return -EINVAL;
+ if (class_max > NF_CT_MAX_EXPECT_CLASSES)
return -EOVERFLOW;
expect_policy = kzalloc(sizeof(struct nf_conntrack_expect_policy) *
- helper->expect_class_max, GFP_KERNEL);
+ class_max, GFP_KERNEL);
if (expect_policy == NULL)
return -ENOMEM;
- for (i=0; i<helper->expect_class_max; i++) {
+ for (i = 0; i < class_max; i++) {
if (!tb[NFCTH_POLICY_SET+i])
goto err;
@@ -191,6 +191,8 @@ nfnl_cthelper_parse_expect_policy(struct
if (ret < 0)
goto err;
}
+
+ helper->expect_class_max = class_max - 1;
helper->expect_policy = expect_policy;
return 0;
err:
@@ -377,10 +379,10 @@ nfnl_cthelper_dump_policy(struct sk_buff
goto nla_put_failure;
if (nla_put_be32(skb, NFCTH_POLICY_SET_NUM,
- htonl(helper->expect_class_max)))
+ htonl(helper->expect_class_max + 1)))
goto nla_put_failure;
- for (i=0; i<helper->expect_class_max; i++) {
+ for (i = 0; i < helper->expect_class_max + 1; i++) {
nest_parms2 = nla_nest_start(skb,
(NFCTH_POLICY_SET+i) | NLA_F_NESTED);
if (nest_parms2 == NULL)
Patches currently in stable-queue which might be from zlpnobody@gmail.com are
queue-3.18/netfilter-invoke-synchronize_rcu-after-set-the-_hook_-to-null.patch
queue-3.18/netfilter-nfnl_cthelper-fix-incorrect-helper-expect_class_max.patch
^ 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.