* [Qemu-devel] [PULL 2/4] usb: fix libusb config variable name.
From: Gerd Hoffmann @ 2017-10-05 9:04 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann, Jan Kiszka
In-Reply-To: <20171005090443.26889-1-kraxel@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Fixes: 4e5ee5b21c84fe3023a64b5cc2e12a52ab0597c1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
Message-id: 20170926063820.30773-1-kraxel@redhat.com
---
hw/usb/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 9255234c63..0e6d54b21f 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -42,7 +42,7 @@ redirect.o-cflags = $(USB_REDIR_CFLAGS)
redirect.o-libs = $(USB_REDIR_LIBS)
# usb pass-through
-ifeq ($(CONFIG_LIBUSB)$(CONFIG_USB),yy)
+ifeq ($(CONFIG_USB_LIBUSB)$(CONFIG_USB),yy)
common-obj-y += host-libusb.o host-legacy.o
else
common-obj-y += host-stub.o
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 4/4] usb: fix host-stub.c build race
From: Gerd Hoffmann @ 2017-10-05 9:04 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
In-Reply-To: <20171005090443.26889-1-kraxel@redhat.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20171004125210.7817-1-kraxel@redhat.com
---
hw/usb/Makefile.objs | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 0e6d54b21f..bdfead6701 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -47,6 +47,7 @@ common-obj-y += host-libusb.o host-legacy.o
else
common-obj-y += host-stub.o
endif
+common-obj-$(CONFIG_ALL) += host-stub.o
host-libusb.o-cflags := $(LIBUSB_CFLAGS)
host-libusb.o-libs := $(LIBUSB_LIBS)
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [PULL 0/4] Usb 20171005 patches
From: Gerd Hoffmann @ 2017-10-05 9:04 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27 22:44:51 +0100)
are available in the git repository at:
git://git.kraxel.org/qemu tags/usb-20171005-pull-request
for you to fetch changes up to eea6ae20379dca837631d603c3bed03e5128189f:
usb: fix host-stub.c build race (2017-10-05 11:03:25 +0200)
----------------------------------------------------------------
usb bugfixes.
----------------------------------------------------------------
Fam Zheng (1):
usb: Use angle brackets for cacard include directive
Gerd Hoffmann (2):
usb: fix libusb config variable name.
usb: fix host-stub.c build race
Thomas Huth (1):
hw/usb/bus: Remove bad object_unparent() from usb_try_create_simple()
hw/usb/bus.c | 4 +---
hw/usb/ccid-card-passthru.c | 2 +-
hw/usb/Makefile.objs | 3 ++-
3 files changed, 4 insertions(+), 5 deletions(-)
--
2.9.3
^ permalink raw reply
* [Qemu-devel] [PULL 3/4] usb: Use angle brackets for cacard include directive
From: Gerd Hoffmann @ 2017-10-05 9:04 UTC (permalink / raw)
To: qemu-devel; +Cc: Fam Zheng, Gerd Hoffmann
In-Reply-To: <20171005090443.26889-1-kraxel@redhat.com>
From: Fam Zheng <famz@redhat.com>
This is a library header, so angle brackets are more appropriate; also
move the line to before QEMU headers, as is recommended in HACKING.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 20170920085952.3872-1-famz@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/usb/ccid-card-passthru.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/ccid-card-passthru.c b/hw/usb/ccid-card-passthru.c
index 45d96b03c6..117711862e 100644
--- a/hw/usb/ccid-card-passthru.c
+++ b/hw/usb/ccid-card-passthru.c
@@ -9,11 +9,11 @@
*/
#include "qemu/osdep.h"
+#include <cacard/vscard_common.h>
#include "chardev/char-fe.h"
#include "qemu/error-report.h"
#include "qemu/sockets.h"
#include "ccid.h"
-#include "cacard/vscard_common.h"
#define DPRINTF(card, lvl, fmt, ...) \
do { \
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 07/10] drm/i915: Gate engine stats collection with a static key
From: Chris Wilson @ 2017-10-05 9:04 UTC (permalink / raw)
To: Tvrtko Ursulin, Tvrtko Ursulin, Intel-gfx
In-Reply-To: <5a25a8b2-d8da-f558-44fb-b9111194358c@linux.intel.com>
Quoting Tvrtko Ursulin (2017-10-05 08:07:03)
>
> On 04/10/2017 18:49, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-10-04 18:38:09)
> >>
> >> On 03/10/2017 11:17, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2017-09-29 13:34:57)
> >>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>>
> >>>> This reduces the cost of the software engine busyness tracking
> >>>> to a single no-op instruction when there are no listeners.
> >>>>
> >>>> We add a new i915 ordered workqueue to be used only for tasks
> >>>> not needing struct mutex.
> >>>>
> >>>> v2: Rebase and some comments.
> >>>> v3: Rebase.
> >>>> v4: Checkpatch fixes.
> >>>> v5: Rebase.
> >>>> v6: Use system_long_wq to avoid being blocked by struct_mutex
> >>>> users.
> >>>> v7: Fix bad conflict resolution from last rebase. (Dmitry Rogozhkin)
> >>>> v8: Rebase.
> >>>> v9:
> >>>> * Fix race between unordered enable followed by disable.
> >>>> (Chris Wilson)
> >>>> * Prettify order of local variable declarations. (Chris Wilson)
> >>>
> >>> Ok, I can't see a downside to enabling the optimisation even if it will
> >>> be global and not per-device/per-engine.
> >>
> >> For this one I did a quick test with gem_exec_nop and I've seen around
> >> 0.5% reduction in time spend in intel_lrc_irq_handler in the case where
> >> PMU is not active.
> >
> > Hmm, gem_exec_nop isn't going to be favourable as there we are just
> > extending the busyness coverage of an engine. I think you want something
> > like gem_sync/sequential (or gem_exec_whisper), as there each engine
> > will be starting and stopping, and delays between engines will
> > accumulate.
>
> Not sure if we are on the same page. Here I was referring to the CPU
> usage in the "irq" (tasklet) handler. gem_exec_nop generates a good
> number of interrupts (8k/s) and shows up in the profile at ~1.8% CPU
> without the static branch optimisation, and ~1.3% with it.
I'm just suggesting that some of the other tests are more sensitive to
delays incurred there, where that ~50% difference in CPU cycles may be
visible to userspace. They may make a more convincing argument?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 3/5] xlnx-zcu102: Specify the valid CPUs
From: Igor Mammedov @ 2017-10-05 9:04 UTC (permalink / raw)
To: Alistair Francis
Cc: Eduardo Habkost, Marcel Apfelbaum,
qemu-devel@nongnu.org Developers, Philippe Mathieu-Daudé
In-Reply-To: <CAKmqyKP6yqWfGbzDnWeeROO=_27TiVSBZvdw1PA5JbRH_m3tcA@mail.gmail.com>
On Wed, 4 Oct 2017 14:39:20 -0700
Alistair Francis <alistair.francis@xilinx.com> wrote:
> On Wed, Oct 4, 2017 at 9:34 AM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Wed, Oct 04, 2017 at 03:08:16PM +0200, Igor Mammedov wrote:
> >> On Wed, 4 Oct 2017 09:28:51 -0300
> >> Eduardo Habkost <ehabkost@redhat.com> wrote:
> >>
> >> > On Wed, Oct 04, 2017 at 01:12:32PM +0200, Igor Mammedov wrote:
> >> > > On Tue, 3 Oct 2017 14:41:17 -0700
> >> > > Alistair Francis <alistair.francis@xilinx.com> wrote:
> >> > >
> >> > > > On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >> > > > > On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
> >> > > > >> List all possible valid CPU options.
> >> > > > >>
> >> > > > >> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> >> > > > >> ---
> >> > > > >>
> >> > > > >> hw/arm/xlnx-zcu102.c | 10 ++++++++++
> >> > > > >> hw/arm/xlnx-zynqmp.c | 16 +++++++++-------
> >> > > > >> include/hw/arm/xlnx-zynqmp.h | 1 +
> >> > > > >> 3 files changed, 20 insertions(+), 7 deletions(-)
> >> > > > >>
> >> > > > >> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
> >> > > > >> index 519a16ed98..039649e522 100644
> >> > > > >> --- a/hw/arm/xlnx-zcu102.c
> >> > > > >> +++ b/hw/arm/xlnx-zcu102.c
> >> > > > >> @@ -98,6 +98,8 @@ static void xlnx_zynqmp_init(XlnxZCU102 *s, MachineState *machine)
> >> > > > >> object_property_add_child(OBJECT(machine), "soc", OBJECT(&s->soc),
> >> > > > >> &error_abort);
> >> > > > >>
> >> > > > >> + object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",
> >> > > > >> + &error_fatal);
> >> > > > >
> >> > > > > Do you have plans to support other CPU types to xlnx_zynqmp in
> >> > > > > the future? If not, I wouldn't bother adding the cpu-type
> >> > > > > property and the extra boilerplate code if it's always going to
> >> > > > > be set to cortex-a53.
> >> > > >
> >> > > > No, it'll always be A53.
> >> > > >
> >> > > > I did think of that, but I also wanted to use the new option! I also
> >> > > > think there is an advantage in sanely handling users '-cpu' option,
> >> > > > before now we just ignored it, so I think it still does give a
> >> > > > benefit. That'll be especially important on the Xilinx tree (sometimes
> >> > > > people use our machines with a different CPU to 'benchmark' or test
> >> > > > other CPUs with our CoSimulation setup). So I think it does make sense
> >> > > > to keep in.
> >> > > if cpu isn't user settable, one could just outright die if cpu_type
> >> > > is not NULL and say that user's CLI is wrong.
> >> > > (i.e. don't give users illusion that they allowed to use '-cpu')
> >> >
> >> > Isn't it exactly what this patch does, by setting:
> >> > mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
> >> > mc->valid_cpu_types = xlnx_zynqmp_valid_cpus;
> >> > ?
> >> >
> >> > Except that "-cpu cortex-a53" won't die, which is a good thing.
> >> allowing "-cpu cortex-a53" here, would allow to use feature parsing
> >> which weren't allowed or were ignored before if user supplied '-cpu'.
> >> so I'd more strict and refuse any -cpu and break CLI that tries to use it
> >> if board has non configurable cpu type. It would be easier to relax
> >> restriction later if necessary.
> >>
> >> using validate_cpus here just to have users for the new code,
> >> doesn't seem like valid justification and at that it makes board
> >> code more complex where it's not necessary and build in cpu type
> >> works just fine.
> >
> > It's up to the board maintainer to decide what's the best option.
> > Both features are independent from each other and can be
> > implemented by machine core.
>
> Noooo!
>
> My hope with this series is that eventually we could hit a state where
> every single machine acts the same way with the -cpu option.
>
> I really don't like what we do now where some boards use it, some
> boards error and some boars just ignore the option. I think we should
> agree on something and every machine should follow the same flow so
> that users know what to expect when they use the -cpu option.
>
> If this means we allow machines to specify they don't support the
> option or only have a single element in the list of supported options
> doesn't really matter, but all machines should do the same thing.
>
> >
> > In either case, the valid_cpu_types feature will be still very
> > useful for boards like pxa270 and sa1110, which support -cpu but
> > only with specific families of CPU types (grep for
> > "strncmp(cpu_type").
> >
> >>
> >> wrt centralized way to refuse -cpu if board doesn't support it,
> >> (which is not really related to this series) following could be done:
> >>
> >> when cpu_model removal is completely done I plan to replace
> >> vl.c
> >> cpu_parse_cpu_model(machine_class->default_cpu_type, cpu_model)
> >> with
> >> cpu_parse_cpu_model(DEFAULT_TARGET_CPU_TYPE, cpu_model)
> >>
> >> so that we could drop temporary guard
> >>
> >> if (machine_class->default_cpu_type) {
> >
> > This sounds good to me, even if we don't reject -cpu on any
> > board.
> >
> >
> >>
> >> with that it would be possible to tell from machine_run_board_init()
> >> that board doesn't provide cpu but user provided '-cpu'
> >> so we would be able to:
> >> if ((machine_class->default_cpu_type == NULL) &&
> >> (machine->cpu_type != NULL))
> >> error_fatal("machine doesn't support -cpu option");
> >
> > I won't complain too much if a board maintainer really wants to
> > make the board reject -cpu completely, but it's up to them.
>
> I disagree. I think a standard way of doing it is better. At least for
> each architecture. The ARM -cpu option is very confusing at the moment
> and it really doesn't need to be that bad.
>
> >
> > Personally, I'd prefer to have all boards setting
> > default_cpu_type even if they support only one CPU model, so
> > clients don't need a special case for boards that don't support
> > -cpu.
>
> I agree, I think having one CPU makes more sense. It makes it easier
> to add support for more cpus in the future and allows the users to use
> the -cpu option without killing QEMU.
I'm considering -cpu option as a legacy one that server 2 purposes now
1: pick cpu type for running instance
2: convert optional features/legacy syntax to global properties
for related cpu type
It plays ok for machines with single type of cpu but doesn't really scale
to more and doesn't work well nor needed if we were to specify cpus on CLI
with -device (i.e. build machine from config/CLI)
So I would not extend usage '-cpu' to boards that have fixed cpu type,
because it really useless in that case and confuses users with idea that
they have ability/need to specify -cpu on fixed cpu board.
I'd be upfront with users and fail explicitly if -cpu is not supported
(yes, it is not uniform CLI behavior across machines but it makes
sense since not all machines are the same, there probably are other
options with which some machines error out with unsupported error,
-cpu is not any different case).
>
> Thanks,
> Alistair
>
> >
> > --
> > Eduardo
> >
^ permalink raw reply
* Re: [PATCH v4] btrfs: Remove received_uuid during received snapshot ro->rw switch
From: Anand Jain @ 2017-10-05 9:03 UTC (permalink / raw)
To: Nikolay Borisov, dsterba; +Cc: linux-btrfs
In-Reply-To: <1507191773-23039-1-git-send-email-nborisov@suse.com>
On 10/05/2017 04:22 PM, Nikolay Borisov wrote:
> Currently when a read-only snapshot is received and subsequently its ro property
> is set to false i.e. switched to rw-mode the received_uuid of that subvol remains
> intact. However, once the received volume is switched to RW mode we cannot
> guaranteee that it contains the same data, so it makes sense to remove the
> received uuid. The presence of the received_uuid can also cause problems when
> the volume is being send.
Wonder if this [1] approach was considered
[1]
- set a flag on the subvolume to indicate its dirtied so that
received_uuid can be kept forever just in case if user needs it for some
reference at a later point of time.
Thanks, Anand
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> Suggested-by: David Sterba <dsterba@suse.cz>
> ---
>
> v4:
> * Put the uuid tree removal code after the lightweight 'send in progress'
> check and don't move btrfs_start_transaction as suggested by David
>
> v3:
> * Rework the patch considering latest feedback from David Sterba i.e.
> explicitly use btrfs_end_transaction
>
> fs/btrfs/ioctl.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index ee4ee7cbba72..9328c091854b 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -1775,6 +1775,7 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
> struct btrfs_trans_handle *trans;
> u64 root_flags;
> u64 flags;
> + bool clear_received_uuid = false;
> int ret = 0;
>
> if (!inode_owner_or_capable(inode))
> @@ -1824,6 +1825,7 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
> btrfs_set_root_flags(&root->root_item,
> root_flags & ~BTRFS_ROOT_SUBVOL_RDONLY);
> spin_unlock(&root->root_item_lock);
> + clear_received_uuid = true;
> } else {
> spin_unlock(&root->root_item_lock);
> btrfs_warn(fs_info,
> @@ -1840,6 +1842,24 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
> goto out_reset;
> }
>
> + if (clear_received_uuid) {
> + if (!btrfs_is_empty_uuid(root->root_item.received_uuid)) {
> + ret = btrfs_uuid_tree_rem(trans, fs_info,
> + root->root_item.received_uuid,
> + BTRFS_UUID_KEY_RECEIVED_SUBVOL,
> + root->root_key.objectid);
> +
> + if (ret && ret != -ENOENT) {
> + btrfs_abort_transaction(trans, ret);
> + btrfs_end_transaction(trans);
> + goto out_reset;
> + }
> +
> + memset(root->root_item.received_uuid, 0,
> + BTRFS_UUID_SIZE);
> + }
> + }
> +
> ret = btrfs_update_root(trans, fs_info->tree_root,
> &root->root_key, &root->root_item);
> if (ret < 0) {
>
^ permalink raw reply
* Patch "xfs: remove kmem_zalloc_greedy" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: darrick.wong, gregkh, hch; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
xfs: remove kmem_zalloc_greedy
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:
xfs-remove-kmem_zalloc_greedy.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: "Darrick J. Wong" <darrick.wong@oracle.com>
Date: Mon, 6 Mar 2017 11:58:20 -0800
Subject: xfs: remove kmem_zalloc_greedy
From: "Darrick J. Wong" <darrick.wong@oracle.com>
[ Upstream commit 08b005f1333154ae5b404ca28766e0ffb9f1c150 ]
The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
it to grab 1-4 pages for staging of inobt records. The infinite loop in
the greedy allocation function is causing hangs[1] in generic/269, so
just get rid of the greedy allocator in favor of kmem_zalloc_large.
This makes bulkstat somewhat more likely to ENOMEM if there's really no
pages to spare, but eliminates a source of hangs.
[1] http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2: remove single-page fallback
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/kmem.c | 18 ------------------
fs/xfs/kmem.h | 2 --
fs/xfs/xfs_itable.c | 6 ++----
3 files changed, 2 insertions(+), 24 deletions(-)
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -24,24 +24,6 @@
#include "kmem.h"
#include "xfs_message.h"
-/*
- * Greedy allocation. May fail and may return vmalloced memory.
- */
-void *
-kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize)
-{
- void *ptr;
- size_t kmsize = maxsize;
-
- while (!(ptr = vzalloc(kmsize))) {
- if ((kmsize >>= 1) <= minsize)
- kmsize = minsize;
- }
- if (ptr)
- *size = kmsize;
- return ptr;
-}
-
void *
kmem_alloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/kmem.h
+++ b/fs/xfs/kmem.h
@@ -66,8 +66,6 @@ extern void *kmem_realloc(const void *,
extern void kmem_free(const void *);
-extern void *kmem_zalloc_greedy(size_t *, size_t, size_t);
-
static inline void *
kmem_zalloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/xfs_itable.c
+++ b/fs/xfs/xfs_itable.c
@@ -356,7 +356,6 @@ xfs_bulkstat(
xfs_agino_t agino; /* inode # in allocation group */
xfs_agnumber_t agno; /* allocation group number */
xfs_btree_cur_t *cur; /* btree cursor for ialloc btree */
- size_t irbsize; /* size of irec buffer in bytes */
xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */
int nirbuf; /* size of irbuf */
int ubcount; /* size of user's buffer */
@@ -383,11 +382,10 @@ xfs_bulkstat(
*ubcountp = 0;
*done = 0;
- irbuf = kmem_zalloc_greedy(&irbsize, PAGE_SIZE, PAGE_SIZE * 4);
+ irbuf = kmem_zalloc_large(PAGE_SIZE * 4, KM_SLEEP);
if (!irbuf)
return -ENOMEM;
-
- nirbuf = irbsize / sizeof(*irbuf);
+ nirbuf = (PAGE_SIZE * 4) / sizeof(*irbuf);
/*
* Loop over the allocation groups, starting from the last
Patches currently in stable-queue which might be from darrick.wong@oracle.com are
queue-3.18/xfs-remove-kmem_zalloc_greedy.patch
^ permalink raw reply
* Patch "USB: serial: mos7720: fix control-message error handling" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: johan, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: mos7720: fix control-message error handling
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:
usb-serial-mos7720-fix-control-message-error-handling.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: Johan Hovold <johan@kernel.org>
Date: Thu, 12 Jan 2017 14:56:17 +0100
Subject: USB: serial: mos7720: fix control-message error handling
From: Johan Hovold <johan@kernel.org>
[ Upstream commit 0d130367abf582e7cbf60075c2a7ab53817b1d14 ]
Make sure to log an error on short transfers when reading a device
register.
Also clear the provided buffer (which if often an uninitialised
automatic variable) on errors as the driver currently does not bother to
check for errors.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/mos7720.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -236,11 +236,16 @@ static int read_mos_reg(struct usb_seria
status = usb_control_msg(usbdev, pipe, request, requesttype, value,
index, buf, 1, MOS_WDR_TIMEOUT);
- if (status == 1)
+ if (status == 1) {
*data = *buf;
- else if (status < 0)
+ } else {
dev_err(&usbdev->dev,
"mos7720: usb_control_msg() failed: %d\n", status);
+ if (status >= 0)
+ status = -EIO;
+ *data = 0;
+ }
+
kfree(buf);
return status;
Patches currently in stable-queue which might be from johan@kernel.org are
queue-3.18/usb-serial-mos7720-fix-control-message-error-handling.patch
queue-3.18/usb-serial-mos7840-fix-control-message-error-handling.patch
^ permalink raw reply
* Patch "USB: serial: mos7840: fix control-message error handling" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: johan, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: serial: mos7840: fix control-message error handling
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:
usb-serial-mos7840-fix-control-message-error-handling.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: Johan Hovold <johan@kernel.org>
Date: Thu, 12 Jan 2017 14:56:18 +0100
Subject: USB: serial: mos7840: fix control-message error handling
From: Johan Hovold <johan@kernel.org>
[ Upstream commit cd8db057e93ddaacbec025b567490555d2bca280 ]
Make sure to detect short transfers when reading a device register.
The modem-status handling had sufficient error checks in place, but move
handling of short transfers into the register accessor function itself
for consistency.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/mos7840.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -285,9 +285,15 @@ static int mos7840_get_reg_sync(struct u
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
MCS_RD_RTYPE, 0, reg, buf, VENDOR_READ_LENGTH,
MOS_WDR_TIMEOUT);
+ if (ret < VENDOR_READ_LENGTH) {
+ if (ret >= 0)
+ ret = -EIO;
+ goto out;
+ }
+
*val = buf[0];
dev_dbg(&port->dev, "%s offset is %x, return val %x\n", __func__, reg, *val);
-
+out:
kfree(buf);
return ret;
}
@@ -353,8 +359,13 @@ static int mos7840_get_uart_reg(struct u
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
MCS_RD_RTYPE, Wval, reg, buf, VENDOR_READ_LENGTH,
MOS_WDR_TIMEOUT);
+ if (ret < VENDOR_READ_LENGTH) {
+ if (ret >= 0)
+ ret = -EIO;
+ goto out;
+ }
*val = buf[0];
-
+out:
kfree(buf);
return ret;
}
@@ -1518,10 +1529,10 @@ static int mos7840_tiocmget(struct tty_s
return -ENODEV;
status = mos7840_get_uart_reg(port, MODEM_STATUS_REGISTER, &msr);
- if (status != 1)
+ if (status < 0)
return -EIO;
status = mos7840_get_uart_reg(port, MODEM_CONTROL_REGISTER, &mcr);
- if (status != 1)
+ if (status < 0)
return -EIO;
result = ((mcr & MCR_DTR) ? TIOCM_DTR : 0)
| ((mcr & MCR_RTS) ? TIOCM_RTS : 0)
Patches currently in stable-queue which might be from johan@kernel.org are
queue-3.18/usb-serial-mos7720-fix-control-message-error-handling.patch
queue-3.18/usb-serial-mos7840-fix-control-message-error-handling.patch
^ permalink raw reply
* Patch "usb: plusb: Add support for PL-27A1" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: roed, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: plusb: Add support for PL-27A1
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:
usb-plusb-add-support-for-pl-27a1.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: Roman Spychała <roed@onet.eu>
Date: Thu, 20 Apr 2017 12:04:10 +0200
Subject: usb: plusb: Add support for PL-27A1
From: Roman Spychała <roed@onet.eu>
[ Upstream commit 6f2aee0c0de65013333bbc26fe50c9c7b09a37f7 ]
This patch adds support for the PL-27A1 by adding the appropriate
USB ID's. This chip is used in the goobay Active USB 3.0 Data Link
and Unitek Y-3501 cables.
Signed-off-by: Roman Spychała <roed@onet.eu>
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>
---
drivers/net/usb/Kconfig | 2 +-
drivers/net/usb/plusb.c | 15 +++++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -350,7 +350,7 @@ config USB_NET_NET1080
optionally with LEDs that indicate traffic
config USB_NET_PLUSB
- tristate "Prolific PL-2301/2302/25A1 based cables"
+ tristate "Prolific PL-2301/2302/25A1/27A1 based cables"
# if the handshake/init/reset problems, from original 'plusb',
# are ever resolved ... then remove "experimental"
depends on USB_USBNET
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -102,7 +102,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_info prolific_info = {
- .description = "Prolific PL-2301/PL-2302/PL-25A1",
+ .description = "Prolific PL-2301/PL-2302/PL-25A1/PL-27A1",
.flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
@@ -139,6 +139,17 @@ static const struct usb_device_id produc
* Host-to-Host Cable
*/
.driver_info = (unsigned long) &prolific_info,
+
+},
+
+/* super speed cables */
+{
+ USB_DEVICE(0x067b, 0x27a1), /* PL-27A1, no eeprom
+ * also: goobay Active USB 3.0
+ * Data Link,
+ * Unitek Y-3501
+ */
+ .driver_info = (unsigned long) &prolific_info,
},
{ }, // END
@@ -158,5 +169,5 @@ static struct usb_driver plusb_driver =
module_usb_driver(plusb_driver);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/27A1 USB Host to Host Link Driver");
MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from roed@onet.eu are
queue-3.18/usb-plusb-add-support-for-pl-27a1.patch
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Michal Hocko @ 2017-10-05 7:54 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Alan Cox, Christoph Hellwig, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20171004185906.GB2136@cmpxchg.org>
On Wed 04-10-17 14:59:06, Johannes Weiner wrote:
> This reverts commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb and
> commit 171012f561274784160f666f8398af8b42216e1f.
>
> 5d17a73a2ebe ("vmalloc: back off when the current task is killed")
> made all vmalloc allocations from a signal-killed task fail. We have
> seen crashes in the tty driver from this, where a killed task exiting
> tries to switch back to N_TTY, fails n_tty_open because of the vmalloc
> failing, and later crashes when dereferencing tty->disc_data.
>
> Arguably, relying on a vmalloc() call to succeed in order to properly
> exit a task is not the most robust way of doing things. There will be
> a follow-up patch to the tty code to fall back to the N_NULL ldisc.
>
> But the justification to make that vmalloc() call fail like this isn't
> convincing, either. The patch mentions an OOM victim exhausting the
> memory reserves and thus deadlocking the machine. But the OOM killer
> is only one, improbable source of fatal signals. It doesn't make sense
> to fail allocations preemptively with plenty of memory in most cases.
>
> The patch doesn't mention real-life instances where vmalloc sites
> would exhaust memory, which makes it sound more like a theoretical
> issue to begin with. But just in case, the OOM access to memory
> reserves has been restricted on the allocator side in cd04ae1e2dc8
> ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access"),
> which should take care of any theoretical concerns on that front.
>
> Revert this patch, and the follow-up that suppresses the allocation
> warnings when we fail the allocations due to a signal.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> mm/vmalloc.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 8a43db6284eb..673942094328 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1695,11 +1695,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> for (i = 0; i < area->nr_pages; i++) {
> struct page *page;
>
> - if (fatal_signal_pending(current)) {
> - area->nr_pages = i;
> - goto fail_no_warn;
> - }
> -
> if (node == NUMA_NO_NODE)
> page = alloc_page(alloc_mask|highmem_mask);
> else
> @@ -1723,7 +1718,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> warn_alloc(gfp_mask, NULL,
> "vmalloc: allocation failure, allocated %ld of %ld bytes",
> (area->nr_pages*PAGE_SIZE), area->size);
> -fail_no_warn:
> vfree(area->addr);
> return NULL;
> }
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Patch "tty: goldfish: Fix a parameter of a call to free_irq" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: christophe.jaillet, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
tty: goldfish: Fix a parameter of a call to free_irq
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:
tty-goldfish-fix-a-parameter-of-a-call-to-free_irq.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: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon, 9 Jan 2017 01:26:37 +0100
Subject: tty: goldfish: Fix a parameter of a call to free_irq
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
[ Upstream commit 1a5c2d1de7d35f5eb9793266237903348989502b ]
'request_irq()' and 'free_irq()' should be called with the same dev_id.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/goldfish.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -295,7 +295,7 @@ static int goldfish_tty_probe(struct pla
tty_unregister_device(goldfish_tty_driver, i);
err_tty_register_device_failed:
- free_irq(irq, pdev);
+ free_irq(irq, qtty);
err_request_irq_failed:
goldfish_tty_current_line_count--;
if (goldfish_tty_current_line_count == 0)
Patches currently in stable-queue which might be from christophe.jaillet@wanadoo.fr are
queue-3.18/tty-goldfish-fix-a-parameter-of-a-call-to-free_irq.patch
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Michal Hocko @ 2017-10-05 7:54 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Alan Cox, Christoph Hellwig, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20171004185906.GB2136@cmpxchg.org>
On Wed 04-10-17 14:59:06, Johannes Weiner wrote:
> This reverts commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb and
> commit 171012f561274784160f666f8398af8b42216e1f.
>
> 5d17a73a2ebe ("vmalloc: back off when the current task is killed")
> made all vmalloc allocations from a signal-killed task fail. We have
> seen crashes in the tty driver from this, where a killed task exiting
> tries to switch back to N_TTY, fails n_tty_open because of the vmalloc
> failing, and later crashes when dereferencing tty->disc_data.
>
> Arguably, relying on a vmalloc() call to succeed in order to properly
> exit a task is not the most robust way of doing things. There will be
> a follow-up patch to the tty code to fall back to the N_NULL ldisc.
>
> But the justification to make that vmalloc() call fail like this isn't
> convincing, either. The patch mentions an OOM victim exhausting the
> memory reserves and thus deadlocking the machine. But the OOM killer
> is only one, improbable source of fatal signals. It doesn't make sense
> to fail allocations preemptively with plenty of memory in most cases.
>
> The patch doesn't mention real-life instances where vmalloc sites
> would exhaust memory, which makes it sound more like a theoretical
> issue to begin with. But just in case, the OOM access to memory
> reserves has been restricted on the allocator side in cd04ae1e2dc8
> ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access"),
> which should take care of any theoretical concerns on that front.
>
> Revert this patch, and the follow-up that suppresses the allocation
> warnings when we fail the allocations due to a signal.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> mm/vmalloc.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 8a43db6284eb..673942094328 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1695,11 +1695,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> for (i = 0; i < area->nr_pages; i++) {
> struct page *page;
>
> - if (fatal_signal_pending(current)) {
> - area->nr_pages = i;
> - goto fail_no_warn;
> - }
> -
> if (node == NUMA_NO_NODE)
> page = alloc_page(alloc_mask|highmem_mask);
> else
> @@ -1723,7 +1718,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> warn_alloc(gfp_mask, NULL,
> "vmalloc: allocation failure, allocated %ld of %ld bytes",
> (area->nr_pages*PAGE_SIZE), area->size);
> -fail_no_warn:
> vfree(area->addr);
> return NULL;
> }
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v2 7/8] arm64: dts: renesas: initial Eagle board device tree
From: Simon Horman @ 2017-10-05 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUfRr-X_+pZhmWw28SDwa5=7daSefjVaT9y5cFB9VoO6Q@mail.gmail.com>
On Wed, Oct 04, 2017 at 01:10:26PM +0200, Geert Uytterhoeven wrote:
> Hi Sergei,
>
> On Wed, Oct 4, 2017 at 1:03 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > On 9/21/2017 4:18 PM, Geert Uytterhoeven wrote:
> >>> Add the initial device tree for the R8A77970 SoC based Eagle board.
> >>> The board has 1 debug serial port (SCIF0); include support for it,
> >>> so that the serial console can work.
> >>>
> >>> Based on the original (and large) patch by Vladimir Barinov
> >>> <vladimir.barinov@cogentembedded.com>.
> >>>
> >>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>
> >>> --- /dev/null
> >>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
>
> >>> +&extal_clk {
> >>> + clock-frequency = <16666666>;
> >>
> >>
> >> Nitpicking: the schematics say 16.6666 MHz
> >> At 100 ppm accuracy that's the same, though.
> >
> > So, you still want me to change this freq?
>
> I don't think that's really needed, as the difference is smaller than the
> accuracy anyway.
Thanks, I have applied this patch for v4.15.
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: initial Eagle board device tree
From: Simon Horman @ 2017-10-05 9:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sergei Shtylyov, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree@vger.kernel.org, Mark Rutland,
Magnus Damm, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdUfRr-X_+pZhmWw28SDwa5=7daSefjVaT9y5cFB9VoO6Q@mail.gmail.com>
On Wed, Oct 04, 2017 at 01:10:26PM +0200, Geert Uytterhoeven wrote:
> Hi Sergei,
>
> On Wed, Oct 4, 2017 at 1:03 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > On 9/21/2017 4:18 PM, Geert Uytterhoeven wrote:
> >>> Add the initial device tree for the R8A77970 SoC based Eagle board.
> >>> The board has 1 debug serial port (SCIF0); include support for it,
> >>> so that the serial console can work.
> >>>
> >>> Based on the original (and large) patch by Vladimir Barinov
> >>> <vladimir.barinov@cogentembedded.com>.
> >>>
> >>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>
> >>> --- /dev/null
> >>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
>
> >>> +&extal_clk {
> >>> + clock-frequency = <16666666>;
> >>
> >>
> >> Nitpicking: the schematics say 16.6666 MHz
> >> At 100 ppm accuracy that's the same, though.
> >
> > So, you still want me to change this freq?
>
> I don't think that's really needed, as the difference is smaller than the
> accuracy anyway.
Thanks, I have applied this patch for v4.15.
^ permalink raw reply
* Patch "team: fix memory leaks" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: bianpan2016, alexander.levin, davem, gregkh, jiri; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
team: fix memory leaks
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:
team-fix-memory-leaks.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: Pan Bian <bianpan2016@163.com>
Date: Mon, 24 Apr 2017 18:29:16 +0800
Subject: team: fix memory leaks
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit 72ec0bc64b9a5d8e0efcb717abfc757746b101b7 ]
In functions team_nl_send_port_list_get() and
team_nl_send_options_get(), pointer skb keeps the return value of
nlmsg_new(). When the call to genlmsg_put() fails, the memory is not
freed(). This will result in memory leak bugs.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Acked-by: Jiri Pirko <jiri@mellanox.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>
---
drivers/net/team/team.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2331,8 +2331,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags | NLM_F_MULTI,
TEAM_CMD_OPTIONS_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
@@ -2599,8 +2601,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags | NLM_F_MULTI,
TEAM_CMD_PORT_LIST_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
Patches currently in stable-queue which might be from bianpan2016@163.com are
queue-3.18/team-fix-memory-leaks.patch
^ permalink raw reply
* Patch "RDS: RDMA: Fix the composite message user notification" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: santosh.shilimkar, alexander.levin, gregkh, venkat.x.venkatsubra
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
RDS: RDMA: Fix the composite message user notification
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:
rds-rdma-fix-the-composite-message-user-notification.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: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date: Thu, 18 Feb 2016 20:06:47 -0800
Subject: RDS: RDMA: Fix the composite message user notification
From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
[ Upstream commit 941f8d55f6d613a460a5e080d25a38509f45eb75 ]
When application sends an RDS RDMA composite message consist of
RDMA transfer to be followed up by non RDMA payload, it expect to
be notified *only* when the full message gets delivered. RDS RDMA
notification doesn't behave this way though.
Thanks to Venkat for debug and root casuing the issue
where only first part of the message(RDMA) was
successfully delivered but remainder payload delivery failed.
In that case, application should not be notified with
a false positive of message delivery success.
Fix this case by making sure the user gets notified only after
the full message delivery.
Reviewed-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/ib_send.c | 25 +++++++++++++++----------
net/rds/rdma.c | 10 ++++++++++
net/rds/rds.h | 1 +
net/rds/send.c | 4 +++-
4 files changed, 29 insertions(+), 11 deletions(-)
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -102,16 +102,6 @@ static void rds_ib_send_complete(struct
complete(rm, notify_status);
}
-static void rds_ib_send_unmap_data(struct rds_ib_connection *ic,
- struct rm_data_op *op,
- int wc_status)
-{
- if (op->op_nents)
- ib_dma_unmap_sg(ic->i_cm_id->device,
- op->op_sg, op->op_nents,
- DMA_TO_DEVICE);
-}
-
static void rds_ib_send_unmap_rdma(struct rds_ib_connection *ic,
struct rm_rdma_op *op,
int wc_status)
@@ -172,6 +162,21 @@ static void rds_ib_send_unmap_atomic(str
rds_ib_stats_inc(s_ib_atomic_fadd);
}
+static void rds_ib_send_unmap_data(struct rds_ib_connection *ic,
+ struct rm_data_op *op,
+ int wc_status)
+{
+ struct rds_message *rm = container_of(op, struct rds_message, data);
+
+ if (op->op_nents)
+ ib_dma_unmap_sg(ic->i_cm_id->device,
+ op->op_sg, op->op_nents,
+ DMA_TO_DEVICE);
+
+ if (rm->rdma.op_active && rm->data.op_notify)
+ rds_ib_send_unmap_rdma(ic, &rm->rdma, wc_status);
+}
+
/*
* Unmap the resources associated with a struct send_work.
*
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -625,6 +625,16 @@ int rds_cmsg_rdma_args(struct rds_sock *
}
op->op_notifier->n_user_token = args->user_token;
op->op_notifier->n_status = RDS_RDMA_SUCCESS;
+
+ /* Enable rmda notification on data operation for composite
+ * rds messages and make sure notification is enabled only
+ * for the data operation which follows it so that application
+ * gets notified only after full message gets delivered.
+ */
+ if (rm->data.op_sg) {
+ rm->rdma.op_notify = 0;
+ rm->data.op_notify = !!(args->flags & RDS_RDMA_NOTIFY_ME);
+ }
}
/* The cookie contains the R_Key of the remote memory region, and
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -360,6 +360,7 @@ struct rds_message {
} rdma;
struct rm_data_op {
unsigned int op_active:1;
+ unsigned int op_notify:1;
unsigned int op_nents;
unsigned int op_count;
struct scatterlist *op_sg;
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -425,12 +425,14 @@ void rds_rdma_send_complete(struct rds_m
struct rm_rdma_op *ro;
struct rds_notifier *notifier;
unsigned long flags;
+ unsigned int notify = 0;
spin_lock_irqsave(&rm->m_rs_lock, flags);
+ notify = rm->rdma.op_notify | rm->data.op_notify;
ro = &rm->rdma;
if (test_bit(RDS_MSG_ON_SOCK, &rm->m_flags) &&
- ro->op_active && ro->op_notify && ro->op_notifier) {
+ ro->op_active && notify && ro->op_notifier) {
notifier = ro->op_notifier;
rs = rm->m_rs;
sock_hold(rds_rs_to_sk(rs));
Patches currently in stable-queue which might be from santosh.shilimkar@oracle.com are
queue-3.18/rds-ib-add-error-handle.patch
queue-3.18/rds-rdma-fix-the-composite-message-user-notification.patch
^ permalink raw reply
* Patch "sh_eth: use correct name for ECMR_MPDE bit" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: niklas.soderlund+renesas, alexander.levin, davem, gregkh,
sergei.shtylyov
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
sh_eth: use correct name for ECMR_MPDE bit
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:
sh_eth-use-correct-name-for-ecmr_mpde-bit.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: Niklas S�derlund <niklas.soderlund+renesas@ragnatech.se>
Date: Mon, 9 Jan 2017 16:34:04 +0100
Subject: sh_eth: use correct name for ECMR_MPDE bit
From: Niklas S�derlund <niklas.soderlund+renesas@ragnatech.se>
[ Upstream commit 6dcf45e514974a1ff10755015b5e06746a033e5f ]
This bit was wrongly named due to a typo, Sergei checked the SH7734/63
manuals and this bit should be named MPDE.
Suggested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
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>
---
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -326,7 +326,7 @@ enum FELIC_MODE_BIT {
ECMR_DPAD = 0x00200000, ECMR_RZPF = 0x00100000,
ECMR_ZPF = 0x00080000, ECMR_PFR = 0x00040000, ECMR_RXF = 0x00020000,
ECMR_TXF = 0x00010000, ECMR_MCT = 0x00002000, ECMR_PRCEF = 0x00001000,
- ECMR_PMDE = 0x00000200, ECMR_RE = 0x00000040, ECMR_TE = 0x00000020,
+ ECMR_MPDE = 0x00000200, ECMR_RE = 0x00000040, ECMR_TE = 0x00000020,
ECMR_RTM = 0x00000010, ECMR_ILB = 0x00000008, ECMR_ELB = 0x00000004,
ECMR_DM = 0x00000002, ECMR_PRM = 0x00000001,
};
Patches currently in stable-queue which might be from niklas.soderlund+renesas@ragnatech.se are
queue-3.18/sh_eth-use-correct-name-for-ecmr_mpde-bit.patch
^ permalink raw reply
* Patch "pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: elfring, alexander.levin, gregkh, linus.walleij; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()
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:
pinctrl-mvebu-use-seq_puts-in-mvebu_pinconf_group_dbg_show.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: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 12 Jan 2017 16:51:00 +0100
Subject: pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()
From: Markus Elfring <elfring@users.sourceforge.net>
[ Upstream commit 420dc61642920849d824a0de2aa853db59f5244f ]
Strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -195,11 +195,12 @@ static void mvebu_pinconf_group_dbg_show
seq_printf(s, "o");
seq_printf(s, ")");
}
- } else
- seq_printf(s, "current: UNKNOWN");
+ } else {
+ seq_puts(s, "current: UNKNOWN");
+ }
if (grp->num_settings > 1) {
- seq_printf(s, ", available = [");
+ seq_puts(s, ", available = [");
for (n = 0; n < grp->num_settings; n++) {
if (curr == &grp->settings[n])
continue;
@@ -222,7 +223,7 @@ static void mvebu_pinconf_group_dbg_show
seq_printf(s, ")");
}
}
- seq_printf(s, " ]");
+ seq_puts(s, " ]");
}
return;
}
Patches currently in stable-queue which might be from elfring@users.sourceforge.net are
queue-3.18/pinctrl-mvebu-use-seq_puts-in-mvebu_pinconf_group_dbg_show.patch
^ permalink raw reply
* Patch "rds: ib: add error handle" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: yanjun.zhu, alexander.levin, davem, gregkh, guanglei.li, joe.jin,
junxiao.bi, santosh.shilimkar
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
rds: ib: add error handle
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:
rds-ib-add-error-handle.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: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Tue, 7 Mar 2017 02:48:36 -0500
Subject: rds: ib: add error handle
From: Zhu Yanjun <yanjun.zhu@oracle.com>
[ Upstream commit 3b12f73a5c2977153f28a224392fd4729b50d1dc ]
In the function rds_ib_setup_qp, the error handle is missing. When some
error occurs, it is possible that memory leak occurs. As such, error
handle is added.
Cc: Joe Jin <joe.jin@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Guanglei Li <guanglei.li@oracle.com>
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.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/rds/ib_cm.c | 47 ++++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -298,7 +298,7 @@ static int rds_ib_setup_qp(struct rds_co
ret = PTR_ERR(ic->i_send_cq);
ic->i_send_cq = NULL;
rdsdebug("ib_create_cq send failed: %d\n", ret);
- goto out;
+ goto rds_ibdev_out;
}
ic->i_recv_cq = ib_create_cq(dev, rds_ib_recv_cq_comp_handler,
@@ -308,19 +308,19 @@ static int rds_ib_setup_qp(struct rds_co
ret = PTR_ERR(ic->i_recv_cq);
ic->i_recv_cq = NULL;
rdsdebug("ib_create_cq recv failed: %d\n", ret);
- goto out;
+ goto send_cq_out;
}
ret = ib_req_notify_cq(ic->i_send_cq, IB_CQ_NEXT_COMP);
if (ret) {
rdsdebug("ib_req_notify_cq send failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
ret = ib_req_notify_cq(ic->i_recv_cq, IB_CQ_SOLICITED);
if (ret) {
rdsdebug("ib_req_notify_cq recv failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
/* XXX negotiate max send/recv with remote? */
@@ -344,7 +344,7 @@ static int rds_ib_setup_qp(struct rds_co
ret = rdma_create_qp(ic->i_cm_id, ic->i_pd, &attr);
if (ret) {
rdsdebug("rdma_create_qp failed: %d\n", ret);
- goto out;
+ goto recv_cq_out;
}
ic->i_send_hdrs = ib_dma_alloc_coherent(dev,
@@ -354,7 +354,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_send_hdrs) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent send failed\n");
- goto out;
+ goto qp_out;
}
ic->i_recv_hdrs = ib_dma_alloc_coherent(dev,
@@ -364,7 +364,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_recv_hdrs) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent recv failed\n");
- goto out;
+ goto send_hdrs_dma_out;
}
ic->i_ack = ib_dma_alloc_coherent(dev, sizeof(struct rds_header),
@@ -372,7 +372,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_ack) {
ret = -ENOMEM;
rdsdebug("ib_dma_alloc_coherent ack failed\n");
- goto out;
+ goto recv_hdrs_dma_out;
}
ic->i_sends = vzalloc_node(ic->i_send_ring.w_nr * sizeof(struct rds_ib_send_work),
@@ -380,7 +380,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_sends) {
ret = -ENOMEM;
rdsdebug("send allocation failed\n");
- goto out;
+ goto ack_dma_out;
}
ic->i_recvs = vzalloc_node(ic->i_recv_ring.w_nr * sizeof(struct rds_ib_recv_work),
@@ -388,7 +388,7 @@ static int rds_ib_setup_qp(struct rds_co
if (!ic->i_recvs) {
ret = -ENOMEM;
rdsdebug("recv allocation failed\n");
- goto out;
+ goto sends_out;
}
rds_ib_recv_init_ack(ic);
@@ -396,8 +396,33 @@ static int rds_ib_setup_qp(struct rds_co
rdsdebug("conn %p pd %p mr %p cq %p %p\n", conn, ic->i_pd, ic->i_mr,
ic->i_send_cq, ic->i_recv_cq);
-out:
+ return ret;
+
+sends_out:
+ vfree(ic->i_sends);
+ack_dma_out:
+ ib_dma_free_coherent(dev, sizeof(struct rds_header),
+ ic->i_ack, ic->i_ack_dma);
+recv_hdrs_dma_out:
+ ib_dma_free_coherent(dev, ic->i_recv_ring.w_nr *
+ sizeof(struct rds_header),
+ ic->i_recv_hdrs, ic->i_recv_hdrs_dma);
+send_hdrs_dma_out:
+ ib_dma_free_coherent(dev, ic->i_send_ring.w_nr *
+ sizeof(struct rds_header),
+ ic->i_send_hdrs, ic->i_send_hdrs_dma);
+qp_out:
+ rdma_destroy_qp(ic->i_cm_id);
+recv_cq_out:
+ if (!ib_destroy_cq(ic->i_recv_cq))
+ ic->i_recv_cq = NULL;
+send_cq_out:
+ if (!ib_destroy_cq(ic->i_send_cq))
+ ic->i_send_cq = NULL;
+rds_ibdev_out:
+ rds_ib_remove_conn(rds_ibdev, conn);
rds_ib_dev_put(rds_ibdev);
+
return ret;
}
Patches currently in stable-queue which might be from yanjun.zhu@oracle.com are
queue-3.18/rds-ib-add-error-handle.patch
^ permalink raw reply
* Patch "partitions/efi: Fix integer overflow in GPT size calculation" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: alden.tondettar, alexander.levin, ard.biesheuvel, axboe, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
partitions/efi: Fix integer overflow in GPT size calculation
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:
partitions-efi-fix-integer-overflow-in-gpt-size-calculation.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: Alden Tondettar <alden.tondettar@gmail.com>
Date: Sun, 15 Jan 2017 15:31:56 -0700
Subject: partitions/efi: Fix integer overflow in GPT size calculation
From: Alden Tondettar <alden.tondettar@gmail.com>
[ Upstream commit c5082b70adfe8e1ea1cf4a8eff92c9f260e364d2 ]
If a GUID Partition Table claims to have more than 2**25 entries, the
calculation of the partition table size in alloc_read_gpt_entries() will
overflow a 32-bit integer and not enough space will be allocated for the
table.
Nothing seems to get written out of bounds, but later efi_partition() will
read up to 32768 bytes from a 128 byte buffer, possibly OOPSing or exposing
information to /proc/partitions and uevents.
The problem exists on both 64-bit and 32-bit platforms.
Fix the overflow and also print a meaningful debug message if the table
size is too large.
Signed-off-by: Alden Tondettar <alden.tondettar@gmail.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/partitions/efi.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -293,7 +293,7 @@ static gpt_entry *alloc_read_gpt_entries
if (!gpt)
return NULL;
- count = le32_to_cpu(gpt->num_partition_entries) *
+ count = (size_t)le32_to_cpu(gpt->num_partition_entries) *
le32_to_cpu(gpt->sizeof_partition_entry);
if (!count)
return NULL;
@@ -352,7 +352,7 @@ static int is_gpt_valid(struct parsed_pa
gpt_header **gpt, gpt_entry **ptes)
{
u32 crc, origcrc;
- u64 lastlba;
+ u64 lastlba, pt_size;
if (!ptes)
return 0;
@@ -434,13 +434,20 @@ static int is_gpt_valid(struct parsed_pa
goto fail;
}
+ /* Sanity check partition table size */
+ pt_size = (u64)le32_to_cpu((*gpt)->num_partition_entries) *
+ le32_to_cpu((*gpt)->sizeof_partition_entry);
+ if (pt_size > KMALLOC_MAX_SIZE) {
+ pr_debug("GUID Partition Table is too large: %llu > %lu bytes\n",
+ (unsigned long long)pt_size, KMALLOC_MAX_SIZE);
+ goto fail;
+ }
+
if (!(*ptes = alloc_read_gpt_entries(state, *gpt)))
goto fail;
/* Check the GUID Partition Entry Array CRC */
- crc = efi_crc32((const unsigned char *) (*ptes),
- le32_to_cpu((*gpt)->num_partition_entries) *
- le32_to_cpu((*gpt)->sizeof_partition_entry));
+ crc = efi_crc32((const unsigned char *) (*ptes), pt_size);
if (crc != le32_to_cpu((*gpt)->partition_entry_array_crc32)) {
pr_debug("GUID Partitition Entry Array CRC check failed.\n");
Patches currently in stable-queue which might be from alden.tondettar@gmail.com are
queue-3.18/partitions-efi-fix-integer-overflow-in-gpt-size-calculation.patch
^ permalink raw reply
* Patch "netfilter: invoke synchronize_rcu after set the _hook_ to NULL" 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: invoke synchronize_rcu after set the _hook_ to NULL
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-invoke-synchronize_rcu-after-set-the-_hook_-to-null.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: Sat, 25 Mar 2017 08:53:12 +0800
Subject: netfilter: invoke synchronize_rcu after set the _hook_ to NULL
From: Liping Zhang <zlpnobody@gmail.com>
[ Upstream commit 3b7dabf029478bb80507a6c4500ca94132a2bc0b ]
Otherwise, another CPU may access the invalid pointer. For example:
CPU0 CPU1
- rcu_read_lock();
- pfunc = _hook_;
_hook_ = NULL; -
mod unload -
- pfunc(); // invalid, panic
- rcu_read_unlock();
So we must call synchronize_rcu() to wait the rcu reader to finish.
Also note, in nf_nat_snmp_basic_fini, synchronize_rcu() will be invoked
by later nf_conntrack_helper_unregister, but I'm inclined to add a
explicit synchronize_rcu after set the nf_nat_snmp_hook to NULL. Depend
on such obscure assumptions is not a good idea.
Last, in nfnetlink_cttimeout, we use kfree_rcu to free the time object,
so in cttimeout_exit, invoking rcu_barrier() is not necessary at all,
remove it too.
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/ipv4/netfilter/nf_nat_snmp_basic.c | 1 +
net/netfilter/nf_conntrack_ecache.c | 2 ++
net/netfilter/nf_conntrack_netlink.c | 1 +
net/netfilter/nf_nat_core.c | 2 ++
net/netfilter/nfnetlink_cttimeout.c | 1 +
5 files changed, 7 insertions(+)
--- a/net/ipv4/netfilter/nf_nat_snmp_basic.c
+++ b/net/ipv4/netfilter/nf_nat_snmp_basic.c
@@ -1304,6 +1304,7 @@ static int __init nf_nat_snmp_basic_init
static void __exit nf_nat_snmp_basic_fini(void)
{
RCU_INIT_POINTER(nf_nat_snmp_hook, NULL);
+ synchronize_rcu();
nf_conntrack_helper_unregister(&snmp_trap_helper);
}
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -200,6 +200,7 @@ void nf_conntrack_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
@@ -236,6 +237,7 @@ void nf_ct_expect_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_ct_expect_unregister_notifier);
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3242,6 +3242,7 @@ static void __exit ctnetlink_exit(void)
#ifdef CONFIG_NETFILTER_NETLINK_QUEUE_CT
RCU_INIT_POINTER(nfq_ct_hook, NULL);
#endif
+ synchronize_rcu();
}
module_init(ctnetlink_init);
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -888,6 +888,8 @@ static void __exit nf_nat_cleanup(void)
#ifdef CONFIG_XFRM
RCU_INIT_POINTER(nf_nat_decode_session_hook, NULL);
#endif
+ synchronize_rcu();
+
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
synchronize_net();
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -578,6 +578,7 @@ static void __exit cttimeout_exit(void)
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
RCU_INIT_POINTER(nf_ct_timeout_find_get_hook, NULL);
RCU_INIT_POINTER(nf_ct_timeout_put_hook, NULL);
+ synchronize_rcu();
#endif /* CONFIG_NF_CONNTRACK_TIMEOUT */
}
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
* Patch "parisc: perf: Fix potential NULL pointer dereference" has been added to the 3.18-stable tree
From: gregkh @ 2017-10-05 9:02 UTC (permalink / raw)
To: arvind.yadav.cs, alexander.levin, deller, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
parisc: perf: Fix potential NULL pointer dereference
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:
parisc-perf-fix-potential-null-pointer-dereference.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: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Tue, 14 Mar 2017 15:24:51 +0530
Subject: parisc: perf: Fix potential NULL pointer dereference
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
[ Upstream commit 74e3f6e63da6c8e8246fba1689e040bc926b4a1a ]
Fix potential NULL pointer dereference and clean up
coding style errors (code indent, trailing whitespaces).
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/perf.c | 94 +++++++++++++++++++++++-----------------------
1 file changed, 49 insertions(+), 45 deletions(-)
--- a/arch/parisc/kernel/perf.c
+++ b/arch/parisc/kernel/perf.c
@@ -39,7 +39,7 @@
* the PDC INTRIGUE calls. This is done to eliminate bugs introduced
* in various PDC revisions. The code is much more maintainable
* and reliable this way vs having to debug on every version of PDC
- * on every box.
+ * on every box.
*/
#include <linux/capability.h>
@@ -195,8 +195,8 @@ static int perf_config(uint32_t *image_p
static int perf_release(struct inode *inode, struct file *file);
static int perf_open(struct inode *inode, struct file *file);
static ssize_t perf_read(struct file *file, char __user *buf, size_t cnt, loff_t *ppos);
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t count,
- loff_t *ppos);
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos);
static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
static void perf_start_counters(void);
static int perf_stop_counters(uint32_t *raddr);
@@ -222,7 +222,7 @@ extern void perf_intrigue_disable_perf_c
/*
* configure:
*
- * Configure the cpu with a given data image. First turn off the counters,
+ * Configure the cpu with a given data image. First turn off the counters,
* then download the image, then turn the counters back on.
*/
static int perf_config(uint32_t *image_ptr)
@@ -234,7 +234,7 @@ static int perf_config(uint32_t *image_p
error = perf_stop_counters(raddr);
if (error != 0) {
printk("perf_config: perf_stop_counters = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to write image\n");
@@ -242,7 +242,7 @@ printk("Preparing to write image\n");
error = perf_write_image((uint64_t *)image_ptr);
if (error != 0) {
printk("perf_config: DOWNLOAD = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to start counters\n");
@@ -254,7 +254,7 @@ printk("Preparing to start counters\n");
}
/*
- * Open the device and initialize all of its memory. The device is only
+ * Open the device and initialize all of its memory. The device is only
* opened once, but can be "queried" by multiple processes that know its
* file descriptor.
*/
@@ -298,8 +298,8 @@ static ssize_t perf_read(struct file *fi
* called on the processor that the download should happen
* on.
*/
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t count,
- loff_t *ppos)
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
{
int err;
size_t image_size;
@@ -307,11 +307,11 @@ static ssize_t perf_write(struct file *f
uint32_t interface_type;
uint32_t test;
- if (perf_processor_interface == ONYX_INTF)
+ if (perf_processor_interface == ONYX_INTF)
image_size = PCXU_IMAGE_SIZE;
- else if (perf_processor_interface == CUDA_INTF)
+ else if (perf_processor_interface == CUDA_INTF)
image_size = PCXW_IMAGE_SIZE;
- else
+ else
return -EFAULT;
if (!capable(CAP_SYS_ADMIN))
@@ -331,22 +331,22 @@ static ssize_t perf_write(struct file *f
/* First check the machine type is correct for
the requested image */
- if (((perf_processor_interface == CUDA_INTF) &&
- (interface_type != CUDA_INTF)) ||
- ((perf_processor_interface == ONYX_INTF) &&
- (interface_type != ONYX_INTF)))
+ if (((perf_processor_interface == CUDA_INTF) &&
+ (interface_type != CUDA_INTF)) ||
+ ((perf_processor_interface == ONYX_INTF) &&
+ (interface_type != ONYX_INTF)))
return -EINVAL;
/* Next check to make sure the requested image
is valid */
- if (((interface_type == CUDA_INTF) &&
+ if (((interface_type == CUDA_INTF) &&
(test >= MAX_CUDA_IMAGES)) ||
- ((interface_type == ONYX_INTF) &&
- (test >= MAX_ONYX_IMAGES)))
+ ((interface_type == ONYX_INTF) &&
+ (test >= MAX_ONYX_IMAGES)))
return -EINVAL;
/* Copy the image into the processor */
- if (interface_type == CUDA_INTF)
+ if (interface_type == CUDA_INTF)
return perf_config(cuda_images[test]);
else
return perf_config(onyx_images[test]);
@@ -360,7 +360,7 @@ static ssize_t perf_write(struct file *f
static void perf_patch_images(void)
{
#if 0 /* FIXME!! */
-/*
+/*
* NOTE: this routine is VERY specific to the current TLB image.
* If the image is changed, this routine might also need to be changed.
*/
@@ -368,9 +368,9 @@ static void perf_patch_images(void)
extern void $i_dtlb_miss_2_0();
extern void PA2_0_iva();
- /*
+ /*
* We can only use the lower 32-bits, the upper 32-bits should be 0
- * anyway given this is in the kernel
+ * anyway given this is in the kernel
*/
uint32_t itlb_addr = (uint32_t)&($i_itlb_miss_2_0);
uint32_t dtlb_addr = (uint32_t)&($i_dtlb_miss_2_0);
@@ -378,21 +378,21 @@ static void perf_patch_images(void)
if (perf_processor_interface == ONYX_INTF) {
/* clear last 2 bytes */
- onyx_images[TLBMISS][15] &= 0xffffff00;
+ onyx_images[TLBMISS][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[TLBMISS][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[TLBMISS][16] = (dtlb_addr << 8)&0xffffff00;
onyx_images[TLBMISS][17] = itlb_addr;
/* clear last 2 bytes */
- onyx_images[TLBHANDMISS][15] &= 0xffffff00;
+ onyx_images[TLBHANDMISS][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[TLBHANDMISS][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[TLBHANDMISS][16] = (dtlb_addr << 8)&0xffffff00;
onyx_images[TLBHANDMISS][17] = itlb_addr;
/* clear last 2 bytes */
- onyx_images[BIG_CPI][15] &= 0xffffff00;
+ onyx_images[BIG_CPI][15] &= 0xffffff00;
/* set 2 bytes */
onyx_images[BIG_CPI][15] |= (0x000000ff&((dtlb_addr) >> 24));
onyx_images[BIG_CPI][16] = (dtlb_addr << 8)&0xffffff00;
@@ -405,24 +405,24 @@ static void perf_patch_images(void)
} else if (perf_processor_interface == CUDA_INTF) {
/* Cuda interface */
- cuda_images[TLBMISS][16] =
+ cuda_images[TLBMISS][16] =
(cuda_images[TLBMISS][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[TLBMISS][17] =
+ cuda_images[TLBMISS][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[TLBMISS][18] = (itlb_addr << 16)&0xffff0000;
- cuda_images[TLBHANDMISS][16] =
+ cuda_images[TLBHANDMISS][16] =
(cuda_images[TLBHANDMISS][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[TLBHANDMISS][17] =
+ cuda_images[TLBHANDMISS][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[TLBHANDMISS][18] = (itlb_addr << 16)&0xffff0000;
- cuda_images[BIG_CPI][16] =
+ cuda_images[BIG_CPI][16] =
(cuda_images[BIG_CPI][16]&0xffff0000) |
((dtlb_addr >> 8)&0x0000ffff);
- cuda_images[BIG_CPI][17] =
+ cuda_images[BIG_CPI][17] =
((dtlb_addr << 24)&0xff000000) | ((itlb_addr >> 16)&0x000000ff);
cuda_images[BIG_CPI][18] = (itlb_addr << 16)&0xffff0000;
} else {
@@ -434,7 +434,7 @@ static void perf_patch_images(void)
/*
* ioctl routine
- * All routines effect the processor that they are executed on. Thus you
+ * All routines effect the processor that they are executed on. Thus you
* must be running on the processor that you wish to change.
*/
@@ -460,7 +460,7 @@ static long perf_ioctl(struct file *file
}
/* copy out the Counters */
- if (copy_to_user((void __user *)arg, raddr,
+ if (copy_to_user((void __user *)arg, raddr,
sizeof (raddr)) != 0) {
error = -EFAULT;
break;
@@ -488,7 +488,7 @@ static const struct file_operations perf
.open = perf_open,
.release = perf_release
};
-
+
static struct miscdevice perf_dev = {
MISC_DYNAMIC_MINOR,
PA_PERF_DEV,
@@ -595,7 +595,7 @@ static int perf_stop_counters(uint32_t *
/* OR sticky2 (bit 1496) to counter2 bit 32 */
tmp64 |= (userbuf[23] >> 8) & 0x0000000080000000;
raddr[2] = (uint32_t)tmp64;
-
+
/* Counter3 is bits 1497 to 1528 */
tmp64 = (userbuf[23] >> 7) & 0x00000000ffffffff;
/* OR sticky3 (bit 1529) to counter3 bit 32 */
@@ -617,7 +617,7 @@ static int perf_stop_counters(uint32_t *
userbuf[22] = 0;
userbuf[23] = 0;
- /*
+ /*
* Write back the zeroed bytes + the image given
* the read was destructive.
*/
@@ -625,13 +625,13 @@ static int perf_stop_counters(uint32_t *
} else {
/*
- * Read RDR-15 which contains the counters and sticky bits
+ * Read RDR-15 which contains the counters and sticky bits
*/
if (!perf_rdr_read_ubuf(15, userbuf)) {
return -13;
}
- /*
+ /*
* Clear out the counters
*/
perf_rdr_clear(15);
@@ -644,7 +644,7 @@ static int perf_stop_counters(uint32_t *
raddr[2] = (uint32_t)((userbuf[1] >> 32) & 0x00000000ffffffffUL);
raddr[3] = (uint32_t)(userbuf[1] & 0x00000000ffffffffUL);
}
-
+
return 0;
}
@@ -682,7 +682,7 @@ static int perf_rdr_read_ubuf(uint32_t r
i = tentry->num_words;
while (i--) {
buffer[i] = 0;
- }
+ }
/* Check for bits an even number of 64 */
if ((xbits = width & 0x03f) != 0) {
@@ -808,18 +808,22 @@ static int perf_write_image(uint64_t *me
}
runway = ioremap_nocache(cpu_device->hpa.start, 4096);
+ if (!runway) {
+ pr_err("perf_write_image: ioremap failed!\n");
+ return -ENOMEM;
+ }
/* Merge intrigue bits into Runway STATUS 0 */
tmp64 = __raw_readq(runway + RUNWAY_STATUS) & 0xffecfffffffffffful;
- __raw_writeq(tmp64 | (*memaddr++ & 0x0013000000000000ul),
+ __raw_writeq(tmp64 | (*memaddr++ & 0x0013000000000000ul),
runway + RUNWAY_STATUS);
-
+
/* Write RUNWAY DEBUG registers */
for (i = 0; i < 8; i++) {
__raw_writeq(*memaddr++, runway + RUNWAY_DEBUG);
}
- return 0;
+ return 0;
}
/*
@@ -843,7 +847,7 @@ printk("perf_rdr_write\n");
perf_rdr_shift_out_U(rdr_num, buffer[i]);
} else {
perf_rdr_shift_out_W(rdr_num, buffer[i]);
- }
+ }
}
printk("perf_rdr_write done\n");
}
Patches currently in stable-queue which might be from arvind.yadav.cs@gmail.com are
queue-3.18/parisc-perf-fix-potential-null-pointer-dereference.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.