* [ragnatech:media-tree 2692/2696] drivers/media/rc/gpio-ir-recv.c:38:8: error: implicit declaration of function 'gpiod_get_value'
From: kbuild test robot @ 2017-10-05 8:54 UTC (permalink / raw)
To: Ladislav Michl; +Cc: kbuild-all, Mauro Carvalho Chehab, linux-media, Sean Young
[-- Attachment #1: Type: text/plain, Size: 4445 bytes --]
tree: git://git.ragnatech.se/linux media-tree
head: a8c779eb056e9874c6278151ade857c3ac227db9
commit: eed008e605d13ee4fb64668350be58999e85aac7 [2692/2696] [media] media: rc: gpio-ir-recv: use gpiolib API
config: x86_64-randconfig-s4-10051614 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout eed008e605d13ee4fb64668350be58999e85aac7
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/rc/gpio-ir-recv.c: In function 'gpio_ir_recv_irq':
>> drivers/media/rc/gpio-ir-recv.c:38:8: error: implicit declaration of function 'gpiod_get_value' [-Werror=implicit-function-declaration]
val = gpiod_get_value(gpio_dev->gpiod);
^~~~~~~~~~~~~~~
drivers/media/rc/gpio-ir-recv.c: In function 'gpio_ir_recv_probe':
>> drivers/media/rc/gpio-ir-recv.c:60:20: error: implicit declaration of function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
^~~~~~~~~~~~~~
>> drivers/media/rc/gpio-ir-recv.c:60:46: error: 'GPIOD_IN' undeclared (first use in this function)
gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
^~~~~~~~
drivers/media/rc/gpio-ir-recv.c:60:46: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/media/rc/gpio-ir-recv.c:68:18: error: implicit declaration of function 'gpiod_to_irq' [-Werror=implicit-function-declaration]
gpio_dev->irq = gpiod_to_irq(gpio_dev->gpiod);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/gpiod_get_value +38 drivers/media/rc/gpio-ir-recv.c
32
33 static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
34 {
35 int val;
36 struct gpio_rc_dev *gpio_dev = dev_id;
37
> 38 val = gpiod_get_value(gpio_dev->gpiod);
39 if (val >= 0)
40 ir_raw_event_store_edge(gpio_dev->rcdev, val == 1);
41
42 return IRQ_HANDLED;
43 }
44
45 static int gpio_ir_recv_probe(struct platform_device *pdev)
46 {
47 struct device *dev = &pdev->dev;
48 struct device_node *np = dev->of_node;
49 struct gpio_rc_dev *gpio_dev;
50 struct rc_dev *rcdev;
51 int rc;
52
53 if (!np)
54 return -ENODEV;
55
56 gpio_dev = devm_kzalloc(dev, sizeof(*gpio_dev), GFP_KERNEL);
57 if (!gpio_dev)
58 return -ENOMEM;
59
> 60 gpio_dev->gpiod = devm_gpiod_get(dev, NULL, GPIOD_IN);
61 if (IS_ERR(gpio_dev->gpiod)) {
62 rc = PTR_ERR(gpio_dev->gpiod);
63 /* Just try again if this happens */
64 if (rc != -EPROBE_DEFER)
65 dev_err(dev, "error getting gpio (%d)\n", rc);
66 return rc;
67 }
> 68 gpio_dev->irq = gpiod_to_irq(gpio_dev->gpiod);
69 if (gpio_dev->irq < 0)
70 return gpio_dev->irq;
71
72 rcdev = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
73 if (!rcdev)
74 return -ENOMEM;
75
76 rcdev->priv = gpio_dev;
77 rcdev->device_name = GPIO_IR_DEVICE_NAME;
78 rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
79 rcdev->input_id.bustype = BUS_HOST;
80 rcdev->input_id.vendor = 0x0001;
81 rcdev->input_id.product = 0x0001;
82 rcdev->input_id.version = 0x0100;
83 rcdev->dev.parent = dev;
84 rcdev->driver_name = KBUILD_MODNAME;
85 rcdev->min_timeout = 1;
86 rcdev->timeout = IR_DEFAULT_TIMEOUT;
87 rcdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
88 rcdev->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
89 rcdev->map_name = of_get_property(np, "linux,rc-map-name", NULL);
90 if (!rcdev->map_name)
91 rcdev->map_name = RC_MAP_EMPTY;
92
93 gpio_dev->rcdev = rcdev;
94
95 rc = devm_rc_register_device(dev, rcdev);
96 if (rc < 0) {
97 dev_err(dev, "failed to register rc device (%d)\n", rc);
98 return rc;
99 }
100
101 platform_set_drvdata(pdev, gpio_dev);
102
103 return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq,
104 IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
105 "gpio-ir-recv-irq", gpio_dev);
106 }
107
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23023 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/12] lib/librte_mbuf: add security crypto flags and mbuf fields
From: De Lara Guarch, Pablo @ 2017-10-05 8:54 UTC (permalink / raw)
To: Akhil Goyal, dev@dpdk.org
Cc: Doherty, Declan, hemant.agrawal@nxp.com, Nicolau, Radu,
borisp@mellanox.com, aviadye@mellanox.com, thomas@monjalon.net,
sandeep.malik@nxp.com, jerin.jacob@caviumnetworks.com,
Mcnamara, John, olivier.matz@6wind.com
In-Reply-To: <20171003131413.23846-6-akhil.goyal@nxp.com>
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, October 3, 2017 2:14 PM
> To: dev@dpdk.org
> Cc: Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com; Nicolau,
> Radu <radu.nicolau@intel.com>; borisp@mellanox.com;
> aviadye@mellanox.com; thomas@monjalon.net; sandeep.malik@nxp.com;
> jerin.jacob@caviumnetworks.com; Mcnamara, John
> <john.mcnamara@intel.com>; olivier.matz@6wind.com
> Subject: [PATCH v2 05/12] lib/librte_mbuf: add security crypto flags and
> mbuf fields
>
> From: Boris Pismenny <borisp@mellanox.com>
>
Quick comment about the commit message:
1 - For libraries, there is no need to use "lib/librte...".
The convention is to directly use the library name:
In this case: "mbuf: add security...". Same applies to patch 4.
Also, make sure that the commit message starts with capital letter.
Thanks,
Pablo
> add security crypto flags and update mbuf fields to support IPsec crypto
> offload for transmitted packets, and to indicate crypto result for received
> packets.
>
^ permalink raw reply
* [dim PATCH] dim: cd to dim repo in list-upstreams
From: Jani Nikula @ 2017-10-05 8:53 UTC (permalink / raw)
To: Jani Nikula, intel-gfx
In-Reply-To: <20171003133808.28680-1-jani.nikula@intel.com>
Don't assume current directory works.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
dim | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dim b/dim
index d4c0b72abf6e..79e4fbddd6e1 100755
--- a/dim
+++ b/dim
@@ -1751,6 +1751,8 @@ function dim_list_upstreams
{
local dim_drm_upstream_remote
+ cd $DIM_PREFIX/$DIM_REPO
+
dim_drm_upstream_remote=$(repo_to_remote drm-upstream)
echo origin/master
--
2.11.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: Patch "spi: pxa2xx: Add support for Intel Gemini Lake" has been added to the 4.9-stable tree
From: Mark Brown @ 2017-10-05 8:53 UTC (permalink / raw)
To: Greg KH; +Cc: david.e.box, alexander.levin, jarkko.nikula, stable,
stable-commits
In-Reply-To: <20171005084256.GA25363@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Thu, Oct 05, 2017 at 10:42:56AM +0200, Greg KH wrote:
> On Thu, Oct 05, 2017 at 09:39:09AM +0100, Mark Brown wrote:
> > Hrm, not a great problem with this but this is the first I heard of this
> > being proposed for stable?
> You should have been copied on the original patch submission from Sasha
> for this to be included, let me dig...
> Hm, I don't have my email archives on me, Sasha, you did cc: everyone,
> right?
Ah, so I was copied on a mail but I don't really pay attention to most
of the stable kernels other than the ones you maintain and it looked
like an "I've added this to my tree" it was sitting there unread, though
it did pass through my inbox. Usually these things are more of a
"please pick for stable" than just a patch which caught me out a bit.
Like I say I was just surprised there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] soc: mediatek: place Kconfig for all SoC drivers under menu
From: Jean Delvare @ 2017-10-05 8:52 UTC (permalink / raw)
To: sean.wang
Cc: matthias.bgg, linux-mediatek, arnd, linux-arm-kernel,
linux-kernel
In-Reply-To: <41e81ac2998b171ff4715cb2dc17f15aa10b7518.1507173110.git.sean.wang@mediatek.com>
Hi Sean,
On Thu, 5 Oct 2017 11:17:49 +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add cleanup for placing all Kconfig for all MediaTek SoC drivers under
> the independent menu as other SoCs vendor usually did. Since the menu
> would be shown depending on "ARCH_MEDIATEK || COMPILE_TEST" selected and
> MTK_PMIC_WRAP is still safe compiling with the case of "COMPILE_TEST"
> only, the superfluous dependency for those items under the menu also is
> also being removed for the sake of simplicity.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> drivers/soc/mediatek/Kconfig | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 609bb34..a7d0667 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -1,9 +1,11 @@
> #
> # MediaTek SoC drivers
> #
> +menu "MediaTek SoC drivers"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> +
> config MTK_INFRACFG
> bool "MediaTek INFRACFG Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> select REGMAP
> help
> Say yes here to add support for the MediaTek INFRACFG controller. The
> @@ -12,7 +14,6 @@ config MTK_INFRACFG
>
> config MTK_PMIC_WRAP
> tristate "MediaTek PMIC Wrapper Support"
> - depends on ARCH_MEDIATEK
> depends on RESET_CONTROLLER
> select REGMAP
> help
> @@ -22,7 +23,6 @@ config MTK_PMIC_WRAP
>
> config MTK_SCPSYS
> bool "MediaTek SCPSYS Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> default ARCH_MEDIATEK
> select REGMAP
> select MTK_INFRACFG
> @@ -30,3 +30,5 @@ config MTK_SCPSYS
> help
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
> +
> +endmenu
While trying to test this, I found that I am not able to test-compile
these drivers. The problem is in drivers/soc/Makefile:
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
So while Kconfig lets me select the drivers when COMPILE_TEST is
enabled, the build system itself ignores the directory in which these
drivers reside and they aren't built.
If you really want your drivers to be test-compilable then you must
change the above to:
obj-y += mediatek/
I'll send a patch.
Your patch itself looks good to me.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [PATCH v2] soc: mediatek: place Kconfig for all SoC drivers under menu
From: Jean Delvare @ 2017-10-05 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41e81ac2998b171ff4715cb2dc17f15aa10b7518.1507173110.git.sean.wang@mediatek.com>
Hi Sean,
On Thu, 5 Oct 2017 11:17:49 +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add cleanup for placing all Kconfig for all MediaTek SoC drivers under
> the independent menu as other SoCs vendor usually did. Since the menu
> would be shown depending on "ARCH_MEDIATEK || COMPILE_TEST" selected and
> MTK_PMIC_WRAP is still safe compiling with the case of "COMPILE_TEST"
> only, the superfluous dependency for those items under the menu also is
> also being removed for the sake of simplicity.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> drivers/soc/mediatek/Kconfig | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 609bb34..a7d0667 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -1,9 +1,11 @@
> #
> # MediaTek SoC drivers
> #
> +menu "MediaTek SoC drivers"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> +
> config MTK_INFRACFG
> bool "MediaTek INFRACFG Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> select REGMAP
> help
> Say yes here to add support for the MediaTek INFRACFG controller. The
> @@ -12,7 +14,6 @@ config MTK_INFRACFG
>
> config MTK_PMIC_WRAP
> tristate "MediaTek PMIC Wrapper Support"
> - depends on ARCH_MEDIATEK
> depends on RESET_CONTROLLER
> select REGMAP
> help
> @@ -22,7 +23,6 @@ config MTK_PMIC_WRAP
>
> config MTK_SCPSYS
> bool "MediaTek SCPSYS Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> default ARCH_MEDIATEK
> select REGMAP
> select MTK_INFRACFG
> @@ -30,3 +30,5 @@ config MTK_SCPSYS
> help
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
> +
> +endmenu
While trying to test this, I found that I am not able to test-compile
these drivers. The problem is in drivers/soc/Makefile:
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
So while Kconfig lets me select the drivers when COMPILE_TEST is
enabled, the build system itself ignores the directory in which these
drivers reside and they aren't built.
If you really want your drivers to be test-compilable then you must
change the above to:
obj-y += mediatek/
I'll send a patch.
Your patch itself looks good to me.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH v2] soc: mediatek: place Kconfig for all SoC drivers under menu
From: Jean Delvare @ 2017-10-05 8:52 UTC (permalink / raw)
To: sean.wang
Cc: matthias.bgg, linux-mediatek, arnd, linux-arm-kernel,
linux-kernel
In-Reply-To: <41e81ac2998b171ff4715cb2dc17f15aa10b7518.1507173110.git.sean.wang@mediatek.com>
Hi Sean,
On Thu, 5 Oct 2017 11:17:49 +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add cleanup for placing all Kconfig for all MediaTek SoC drivers under
> the independent menu as other SoCs vendor usually did. Since the menu
> would be shown depending on "ARCH_MEDIATEK || COMPILE_TEST" selected and
> MTK_PMIC_WRAP is still safe compiling with the case of "COMPILE_TEST"
> only, the superfluous dependency for those items under the menu also is
> also being removed for the sake of simplicity.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> drivers/soc/mediatek/Kconfig | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 609bb34..a7d0667 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -1,9 +1,11 @@
> #
> # MediaTek SoC drivers
> #
> +menu "MediaTek SoC drivers"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> +
> config MTK_INFRACFG
> bool "MediaTek INFRACFG Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> select REGMAP
> help
> Say yes here to add support for the MediaTek INFRACFG controller. The
> @@ -12,7 +14,6 @@ config MTK_INFRACFG
>
> config MTK_PMIC_WRAP
> tristate "MediaTek PMIC Wrapper Support"
> - depends on ARCH_MEDIATEK
> depends on RESET_CONTROLLER
> select REGMAP
> help
> @@ -22,7 +23,6 @@ config MTK_PMIC_WRAP
>
> config MTK_SCPSYS
> bool "MediaTek SCPSYS Support"
> - depends on ARCH_MEDIATEK || COMPILE_TEST
> default ARCH_MEDIATEK
> select REGMAP
> select MTK_INFRACFG
> @@ -30,3 +30,5 @@ config MTK_SCPSYS
> help
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
> +
> +endmenu
While trying to test this, I found that I am not able to test-compile
these drivers. The problem is in drivers/soc/Makefile:
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
So while Kconfig lets me select the drivers when COMPILE_TEST is
enabled, the build system itself ignores the directory in which these
drivers reside and they aren't built.
If you really want your drivers to be test-compilable then you must
change the above to:
obj-y += mediatek/
I'll send a patch.
Your patch itself looks good to me.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [cip-dev] CIP testing and kernel maintenance report week 38 and 39
From: Robert Marshall @ 2017-10-05 8:51 UTC (permalink / raw)
To: cip-dev
In-Reply-To: <59D223C3.4030104@codethink.co.uk>
Hi
Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> writes:
> Hi,
>
> this is a a summary of the main tasks performed by the Codethink guys
> during the last couple of weeks. Due to vacations and sickness, we
> have been less active than usual.
>
> + Week 38 and 39 2017
>
> ++ Kernel Maintenance
>
> No significant progress.
>
> ++ CIP testing project
>
> * A script to populate initramfs created and merged. Now initramfs is
> built locally again with the new LAVA. Ben H. helped to solve this
> issue.
> ** #111 https://gitlab.com/cip-project/cip-testing/testing/issues/111
> ** #136 https://gitlab.com/cip-project/cip-testing/testing/issues/136
>
> * LAVA updated. The new release will come with 2017.7 version.
> ** tmp data now is cleared with the new LAVA version
> *** #84 https://gitlab.com/cip-project/cip-testing/testing/issues/84
> ** Verbosity comes with the new LAVA version
> *** #115 https://gitlab.com/cip-project/cip-testing/testing/issues/115
>
We should also report that #139 https://gitlab.com/cip-project/cip-testing/testing/issues/139
is preventing the provisioning of a fresh B at D instance
I've created a branch
https://gitlab.com/rajm/board-at-desk-single-dev/tree/fix-new-kernelci
which enables provisioning but still requires some manual intervention
to get a fully working box
Robert
> +++ Other minor accomplishments
>
> * Added to known issues the health check 30 seconds waste
> ** #56 https://gitlab.com/cip-project/cip-testing/testing/issues/56
>
> * Support request solved. #129
> ** Link: https://gitlab.com/cip-project/cip-testing/testing/issues/129
>
> * Identified a link on the LAVA page that needs to be changed
> ** #133 https://gitlab.com/cip-project/cip-testing/testing/issues/133
>
> ++ Other tasks
>
> * CIP workshop at ELCE
> ** Call for participation for the B at D 101 training session published.
> ** Material and set up required for the training session confirmed and
> discussed with the Linux Foundation.
>
> * Y2038 meeting at ELCE confirmed.
> ** Call for topics among CIP members sent.
> ** Some CIP Members has confirmed their presence. More to come.
>
> Best Regards
^ permalink raw reply
* Re: [GIT PULL for-4.4 00/46] Commits for v4.4 LTS
From: gregkh @ 2017-10-05 8:51 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin); +Cc: stable@vger.kernel.org
In-Reply-To: <20170924184213.29599-1-alexander.levin@verizon.com>
On Sun, Sep 24, 2017 at 06:42:18PM +0000, Levin, Alexander (Sasha Levin) wrote:
> Hi Greg,
>
> The following commits were sent for review 7+ days ago, and comments were addressed.
>
> Please pull for v4.4 LTS.
All now queued up, thanks for these.
greg k-h
^ permalink raw reply
* Patch "xfs: remove kmem_zalloc_greedy" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -69,8 +69,6 @@ static inline 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
@@ -351,7 +351,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 */
@@ -378,11 +377,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-4.4/xfs-remove-kmem_zalloc_greedy.patch
^ permalink raw reply
* Patch "USB: serial: mos7720: fix control-message error handling" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -234,11 +234,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-4.4/usb-serial-mos7720-fix-control-message-error-handling.patch
queue-4.4/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 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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;
}
@@ -1490,10 +1501,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-4.4/usb-serial-mos7720-fix-control-message-error-handling.patch
queue-4.4/usb-serial-mos7840-fix-control-message-error-handling.patch
^ permalink raw reply
* Patch "tty: goldfish: Fix a parameter of a call to free_irq" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -293,7 +293,7 @@ static int goldfish_tty_probe(struct pla
return 0;
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-4.4/tty-goldfish-fix-a-parameter-of-a-call-to-free_irq.patch
^ permalink raw reply
* Patch "usb: plusb: Add support for PL-27A1" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -364,7 +364,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-4.4/usb-plusb-add-support-for-pl-27a1.patch
^ permalink raw reply
* Patch "usb: chipidea: vbus event may exist before starting gadget" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: peter.chen, alexander.levin, gregkh, stephen.boyd; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: chipidea: vbus event may exist before starting gadget
to the 4.4-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-chipidea-vbus-event-may-exist-before-starting-gadget.patch
and it can be found in the queue-4.4 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:49:14 CEST 2017
From: Peter Chen <peter.chen@nxp.com>
Date: Wed, 19 Oct 2016 15:32:58 +0800
Subject: usb: chipidea: vbus event may exist before starting gadget
From: Peter Chen <peter.chen@nxp.com>
[ Upstream commit c3b674a04b8ab62a1d35e86714d466af0a0ecc18 ]
At some situations, the vbus may already be there before starting
gadget. So we need to check vbus event after switching to gadget in
order to handle missing vbus event. The typical use cases are plugging
vbus cable before driver load or the vbus has already been there
after stopping host but before starting gadget.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by: Stephen Boyd <stephen.boyd@linaro.org>
Reported-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/otg.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdr
if (!ci->is_otg)
return;
- if (hw_read_otgsc(ci, OTGSC_BSV))
+ if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
usb_gadget_vbus_connect(&ci->gadget);
- else
+ else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
usb_gadget_vbus_disconnect(&ci->gadget);
}
@@ -175,14 +175,21 @@ static void ci_handle_id_switch(struct c
ci_role_stop(ci);
- if (role == CI_ROLE_GADGET)
+ if (role == CI_ROLE_GADGET &&
+ IS_ERR(ci->platdata->vbus_extcon.edev))
/*
- * wait vbus lower than OTGSC_BSV before connecting
- * to host
+ * Wait vbus lower than OTGSC_BSV before connecting
+ * to host. If connecting status is from an external
+ * connector instead of register, we don't need to
+ * care vbus on the board, since it will not affect
+ * external connector status.
*/
hw_wait_vbus_lower_bsv(ci);
ci_role_start(ci, role);
+ /* vbus change may have already occurred */
+ if (role == CI_ROLE_GADGET)
+ ci_handle_vbus_change(ci);
}
}
/**
Patches currently in stable-queue which might be from peter.chen@nxp.com are
queue-4.4/usb-chipidea-vbus-event-may-exist-before-starting-gadget.patch
^ permalink raw reply
* Patch "RDS: RDMA: Fix the composite message user notification" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -68,16 +68,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)
@@ -138,6 +128,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
@@ -626,6 +626,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
@@ -378,6 +378,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;
unsigned int op_dmasg;
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -467,12 +467,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-4.4/rds-ib-add-error-handle.patch
queue-4.4/rds-rdma-fix-the-composite-message-user-notification.patch
^ permalink raw reply
* Patch "team: fix memory leaks" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -2343,8 +2343,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;
@@ -2611,8 +2613,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-4.4/team-fix-memory-leaks.patch
queue-4.4/drm-amdkfd-fix-improper-return-value-on-error.patch
^ permalink raw reply
* Patch "sh_eth: use correct name for ECMR_MPDE bit" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -339,7 +339,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-4.4/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 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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-4.4/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 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -381,7 +381,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;
}
cq_attr.cqe = ic->i_recv_ring.w_nr;
@@ -392,19 +392,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? */
@@ -428,7 +428,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,
@@ -438,7 +438,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,
@@ -448,7 +448,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),
@@ -456,7 +456,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),
@@ -464,7 +464,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),
@@ -472,7 +472,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);
@@ -480,8 +480,33 @@ static int rds_ib_setup_qp(struct rds_co
rdsdebug("conn %p pd %p cq %p %p\n", conn, ic->i_pd,
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-4.4/rds-ib-add-error-handle.patch
^ permalink raw reply
* Patch "parisc: perf: Fix potential NULL pointer dereference" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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,
@@ -596,7 +596,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 */
@@ -618,7 +618,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.
*/
@@ -626,13 +626,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);
@@ -645,7 +645,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;
}
@@ -683,7 +683,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) {
@@ -809,18 +809,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;
}
/*
@@ -844,7 +848,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-4.4/parisc-perf-fix-potential-null-pointer-dereference.patch
^ permalink raw reply
* Patch "partitions/efi: Fix integer overflow in GPT size calculation" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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-4.4/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 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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 | 2 +-
5 files changed, 7 insertions(+), 1 deletion(-)
--- 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
@@ -3415,6 +3415,7 @@ static void __exit ctnetlink_exit(void)
#ifdef CONFIG_NETFILTER_NETLINK_GLUE_CT
RCU_INIT_POINTER(nfnl_ct_hook, NULL);
#endif
+ synchronize_rcu();
}
module_init(ctnetlink_init);
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -892,6 +892,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
@@ -611,8 +611,8 @@ 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 */
- rcu_barrier();
}
module_init(cttimeout_init);
Patches currently in stable-queue which might be from zlpnobody@gmail.com are
queue-4.4/netfilter-invoke-synchronize_rcu-after-set-the-_hook_-to-null.patch
queue-4.4/netfilter-nfnl_cthelper-fix-incorrect-helper-expect_class_max.patch
^ permalink raw reply
* Patch "netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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-4.4/netfilter-invoke-synchronize_rcu-after-set-the-_hook_-to-null.patch
queue-4.4/netfilter-nfnl_cthelper-fix-incorrect-helper-expect_class_max.patch
^ permalink raw reply
* Patch "net: core: Prevent from dereferencing null pointer when releasing SKB" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 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 4.4-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-4.4 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:49:14 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
@@ -2338,6 +2338,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-4.4/net-core-prevent-from-dereferencing-null-pointer-when-releasing-skb.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.