Re: [PATCH] mm, sparse: fix typo in online_mem_sections
On 09/04/2017 04:52 PM, Michal Hocko wrote: > From: Michal Hocko > > online_mem_sections accidentally marks online only the first section in > the given range. This is a typo which hasn't been noticed because I > haven't tested large 2GB blocks previously. All users of Section sizes are normally less than 2GB. Could you please elaborate why this never got noticed before ?
[PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors
Some functions exposed by pmbus core conflated errors that occurred when
setting the page to access with errors that occurred when accessing
registers in a page. In some cases, this caused legitimate errors to be
hidden under the guise of the register not being supported.
Signed-off-by: Andrew Jeffery
---
Documentation/hwmon/pmbus-core | 12 ++--
drivers/hwmon/pmbus/pmbus.h | 6 +-
drivers/hwmon/pmbus/pmbus_core.c | 115 +--
3 files changed, 95 insertions(+), 38 deletions(-)
diff --git a/Documentation/hwmon/pmbus-core b/Documentation/hwmon/pmbus-core
index 8ed10e9ddfb5..3e9f41bb756f 100644
--- a/Documentation/hwmon/pmbus-core
+++ b/Documentation/hwmon/pmbus-core
@@ -218,17 +218,17 @@ Specifically, it provides the following information.
This function calls the device specific write_byte function if defined.
Therefore, it must _not_ be called from that function.
- bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
+ int pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
- Check if byte register exists. Return true if the register exists, false
- otherwise.
+ Check if byte register exists. Returns 1 if the register exists, 0 if it does
+ not, and less than zero on an unexpected error.
This function calls the device specific write_byte function if defined to
obtain the chip status. Therefore, it must _not_ be called from that
function.
- bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
+ int pmbus_check_word_register(struct i2c_client *client, int page, int reg);
- Check if word register exists. Return true if the register exists, false
- otherwise.
+ Check if word register exists. Returns 1 if the register exists, 0 if it does
+ not, and less than zero on an unexpected error.
This function calls the device specific write_byte function if defined to
obtain the chip status. Therefore, it must _not_ be called from that
function.
diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index bfcb13bae34b..c53032a04a6f 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -413,9 +413,9 @@ int pmbus_write_byte_data(struct i2c_client *client, int
page, u8 reg,
u8 value);
int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
u8 mask, u8 value);
-void pmbus_clear_faults(struct i2c_client *client);
-bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
-bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
+int pmbus_clear_faults(struct i2c_client *client);
+int pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
+int pmbus_check_word_register(struct i2c_client *client, int page, int reg);
int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
struct pmbus_driver_info *info);
int pmbus_do_remove(struct i2c_client *client);
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index f1eff6b6c798..153700e35431 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -304,18 +304,24 @@ static int _pmbus_read_byte_data(struct i2c_client
*client, int page, int reg)
return pmbus_read_byte_data(client, page, reg);
}
-static void pmbus_clear_fault_page(struct i2c_client *client, int page)
+static int pmbus_clear_fault_page(struct i2c_client *client, int page)
{
- _pmbus_write_byte(client, page, PMBUS_CLEAR_FAULTS);
+ return _pmbus_write_byte(client, page, PMBUS_CLEAR_FAULTS);
}
-void pmbus_clear_faults(struct i2c_client *client)
+int pmbus_clear_faults(struct i2c_client *client)
{
struct pmbus_data *data = i2c_get_clientdata(client);
+ int rv;
int i;
- for (i = 0; i < data->info->pages; i++)
- pmbus_clear_fault_page(client, i);
+ for (i = 0; i < data->info->pages; i++) {
+ rv = pmbus_clear_fault_page(client, i);
+ if (rv)
+ return rv;
+ }
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pmbus_clear_faults);
@@ -333,28 +339,45 @@ static int pmbus_check_status_cml(struct i2c_client
*client)
return 0;
}
-static bool pmbus_check_register(struct i2c_client *client,
+static int pmbus_check_register(struct i2c_client *client,
int (*func)(struct i2c_client *client,
int page, int reg),
int page, int reg)
{
+ struct pmbus_data *data;
+ int check;
int rv;
- struct pmbus_data *data = i2c_get_clientdata(client);
- rv = func(client, page, reg);
- if (rv >= 0 && !(data->flags & PMBUS_SKIP_STATUS_CHECK))
- rv = pmbus_check_status_cml(client);
- pmbus_clear_fault_page(client, -1);
- ret
Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
On Thu, 2017-08-31 at 12:23 +, Anna-Maria Gleixner wrote: > From: Thomas Gleixner > > Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer > callback in softirq context and remove the hrtimer_tasklet. > > Signed-off-by: Thomas Gleixner > Signed-off-by: Anna-Maria Gleixner > Cc: Johannes Berg > Cc: Kalle Valo > Cc: linux-wirel...@vger.kernel.org > This looks fine to me, Reviewed-by: Johannes Berg Are you planning to integrate all patches in the series through some other tree, perhaps to be able to get rid of the tasklet_hrtimer API, or should I apply this? johannes
RE: [PATCH v1 1/3] dt-bindings: nvmem: add description for UniPhier eFuse
Hello Yamada-san,
Thank you for your comment.
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Monday, September 4, 2017 9:56 PM
>
> 2017-09-01 8:20 GMT+09:00 Keiji Hayashibara
> :
> > Add uniphier-efuse dt-bindings documentation.
> >
> > Signed-off-by: Keiji Hayashibara
> > ---
> > .../devicetree/bindings/nvmem/uniphier-efuse.txt | 45
> ++
> > 1 file changed, 45 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> > b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> > new file mode 100644
> > index 000..09024a2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> > @@ -0,0 +1,45 @@
> > += UniPhier eFuse device tree bindings =
> > +
> > +This UniPhier eFuse must be under soc-glue.
> > +
> > +Required properties:
> > +- compatible: should be "socionext,uniphier-efuse"
> > +- reg: should contain the register base and length
> > +
> > += Data cells =
> > +Are child nodes of efuse, bindings of which as described in
> > +bindings/nvmem/nvmem.txt
> > +
> > +Example:
> > +
> > + soc-glue@5f90 {
> > + compatible = "socionext,uniphier-ld20-soc-glue-debug",
> > +"simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x5f90 0x2000>;
>
>
> IMHO, I think an empty "ranges;" will clarify the code, but it is up to
> your taste.
>
>
> > +
> > + efuse {
> > + compatible = "socionext,uniphier-efuse",
> > +"syscon";
>
>
> You are adding a dedicated driver for "socionext,uniphier-efuse".
>
> Then, "syscon" as well?
>
Since I was using the syscon interface to implement the driver,
I specified "syscon". It's interface is syscon_node_to_regmap().
I will rethink this in v2.
>
>
> > + reg = <0x100 0xf00>;
>
>
> Not so many efuse registers exist on the SoC.
>
> reg = <0x100 0x200>; will be enough.
>
>
> Or if you want to be strict to the hw spec, you can write as follows:
>
> soc-glue@5f90 {
>compatible = "socionext,uniphier-ld20-soc-glue-debug";
> "simple-mfd";
>#address-cells = <1>;
>#size-cells = <1>;
>ranges = <0x0 0x5f90 0x2000>;
>
>efuse@100 {
>compatible = "socionext,uniphier-efuse";
>reg = <0x100 0x28>;
>};
>
>efuse@200 {
>compatible = "socionext,uniphier-efuse";
>reg = <0x200 0x68>;
>};
>};
>
>
>
>
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + /* Data cells */
> > + usb_mon: usb_mon {
> > + reg = <0x154 0xc>;
> > + };
>
>
> This <0x154 0xc> represents 0x5f900254 in CPU address view.
> (0x5f90 + 0x100 + 0x154)
>
> So many ranges conversion, and how error-prone..
>
Yes, indeed...
I will modify as below.
soc-glue@5f90 {
compatible = "socionext,uniphier-ld20-soc-glue-debug",
"simple-mfd";
#address-cells = <1>;
#size-cells = <1>;
ranges;
efuse@5f900100 {
compatible = "socionext,uniphier-efuse";
reg = <0x5f900100 0x28>;
};
efuse@5f900200 {
compatible = "socionext,uniphier-efuse";
reg = <0x5f900200 0x68>;
};
};
>
>
>
> > + };
> > +
> > += Data consumers =
> > +Are device nodes which consume nvmem data cells.
> > +
> > +Example:
> > +
> > + usb {
> > + ...
> > + nvmem-cells = <&usb_mon>;
> > + nvmem-cell-names = "usb_mon";
> > + }
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Masahiro Yamada
Best Regards,
Keiji Hayashibara
Re: [PATCH] drivers/x86: add thinkpad-wmi
[re-send for the mailing list, I forgot that gmail was stupid]
On Tue, Sep 5, 2017 at 9:05 AM, Corentin Chary wrote:
>
>
> On Mon, Sep 4, 2017 at 7:15 PM, Andy Shevchenko
> wrote:
>>
>> On Mon, Sep 4, 2017 at 11:21 AM, Corentin Chary
>> wrote:
>> > This driver has been available on https://github.com/iksaif/thinkpad-wmi
>> > for
>> > a few year and is already deployed on large fleets of thinkpad laptops.
>> >
>> > The WMI interface is documented here:
>> > http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkcentre_pdf/hrdeploy_en.pdf
>> > It mostly focused on changing BIOS/Firmware settings.
>>
>> I will do full review later, few comments right now though.
>> Thanks for doing this btw.
>>
>> > +Date: Aug 2017
>> > +KernelVersion: 4.14
>>
>> v4.15 apparently
>
>
> Done
>
>>
>>
>> > + * Thinkpad WMI hotkey driver
>>
>> Solely for hot keys?
>>
>
> /hotkey/configuration/
>
>>
>> > + *
>> > + * Copyright(C) 2012 Corentin Chary
>>
>> 2012,2017?
>>
>
> done
>
>>
>>
>> > + * You should have received a copy of the GNU General Public License
>> > + * along with this program; if not, write to the Free Software
>> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
>> > 02111-1307 USA
>>
>> Remove this. It had been changed once, no guarantee it will not again.
>
>
> done
>
>>
>>
>>
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>>
>> Alphabetical.
>>
>
> done
>
>>
>> > +static int __init thinkpad_wmi_init(void)
>> > +{
>> > + platform_device = platform_create_bundle(&platform_driver,
>> > +thinkpad_wmi_probe,
>> > +NULL, 0, NULL, 0);
>> > + if (IS_ERR(platform_device))
>> > + return PTR_ERR(platform_device);
>> > + return 0;
>> > +}
>> > +
>> > +static void __exit thinkpad_wmi_exit(void)
>> > +{
>> > + platform_device_unregister(platform_device);
>> > + platform_driver_unregister(&platform_driver);
>> > +}
>> > +
>> > +module_init(thinkpad_wmi_init);
>> > +module_exit(thinkpad_wmi_exit);
>>
>> I didn't read the code, does it use WMI bus which Andy L. introduced
>> recently?
>>
>
> No, I wasn't aware of it. I checked the dell-wmi conversion patch and it
> should not be too hard.
> I'll probably sent that as a patch on top the existing driver (in the same
> series).
>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>
>
>
>
> --
> Corentin Chary
> http://xf.iksaif.net
--
Corentin Chary
http://xf.iksaif.net
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Tue, Sep 05, 2017 at 09:38:45AM +0900, Byungchul Park wrote:
> On Mon, Sep 04, 2017 at 01:42:48PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote:
> > > On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> > > > And get tangled up with the workqueue annotation again, no thanks.
> > > > Having the first few works see the thread setup isn't worth it.
> > > >
> > > > And your work_id annotation had the same problem.
> > >
> > > I keep asking you for an example because I really understand you.
> > >
> > >Fix my problematic example with your patches,
> > >
> > >or,
> > >
> > >Show me a problematic scenario with my original code, you expect.
> > >
> > > Whatever, it would be helpful to understand you.
> >
> > I _really_ don't understand what you're worried about. Is it the kthread
> > create and workqueue init or the pool->lock that is released/acquired in
> > process_one_work()?
>
> s/in process_one_work()/in all worker code including setup code/
>
> Original code was already designed to handle real dependencies well. But
> you invalidated it _w/o_ any reason, that's why I don't agree with your
> patches.
The reasons:
- it avoids the interaction with the workqueue annotation
- it makes each work consistent
- its not different from what you did with work_id:
https://lkml.kernel.org/r/1489479542-27030-6-git-send-email-byungchul.p...@lge.com
crossrelease_work_start() vs same_context_xhlock() { if
(xhlock->work_id == curr->workid) ... }
> Your patches only do avoiding the wq issue now we focus on.
>
> Look at:
>
> worker thread another context
> - ---
>wait_for_completion()
>|
>| (1)
>v
> +-+
> | Work A | (2)
> +-+
>|
>| (3)
>v
> +-+
> | Work B | (4)
> +-+
>|
>| (5)
>v
> +-+
> | Work C | (6)
> +-+
>|
>v
>
> We have to consider whole context of the worker to build dependencies
> with a crosslock e.g. wait_for_commplete().
>
> Only thing we have to care here is to make all works e.g. (2), (4) and
> (6) independent, because workqueue does _concurrency control_. As I said
> last year at the very beginning, for works not applied the control e.g.
> max_active == 1, we don't need that isolation. I said, it's a future work.
>
> It would have been much easier to communicate with each other if you
> *tried* to understand my examples like now or you *tried* to give me one
> example at least. You didn't even *try*. Only thing I want to ask you
> for is to *try* to understand my opinions on conflicts.
>
> Now, understand what I intended? Still unsufficient?
So you worry about max_active==1 ? Or you worry about pool->lock or
about the thread setup? I'm still not sure.
[PATCH 3.18 0/9] 3.18.70-stable review
This is the start of the stable review cycle for the 3.18.70 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Sep 7 07:08:47 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.70-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.18.70-rc1 Oleg Nesterov epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove() Xiangliang.Yu drm/ttm: Fix accounting error when fail to get pages for pool Vladis Dronov xfrm: policy: check policy direction value Cong Wang wl1251: add a missing spin_lock_init() Steve French CIFS: remove endian related sparse warning Pavel Shilovsky CIFS: Fix maximum SMB2 header size Tejun Heo cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs Stephen Douthit i2c: ismt: Return EMSGSIZE for block reads with bogus length Stephen Douthit i2c: ismt: Don't duplicate the receive length for block reads - Diffstat: Makefile | 4 ++-- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- drivers/i2c/busses/i2c-ismt.c | 6 -- drivers/net/wireless/ti/wl1251/main.c | 1 + fs/cifs/dir.c | 2 +- fs/cifs/smb2pdu.h | 4 ++-- fs/eventpoll.c| 37 +++ include/asm-generic/topology.h| 6 +- net/xfrm/xfrm_policy.c| 6 ++ 9 files changed, 46 insertions(+), 22 deletions(-)
[PATCH 3.18 6/9] wl1251: add a missing spin_lock_init()
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Cong Wang commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ti/wl1251/main.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1572,6 +1572,7 @@ struct ieee80211_hw *wl1251_alloc_hw(voi wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE;
[PATCH 3.18 3/9] cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit b339752d054fb32863418452dff350a1086885b1 upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by: Tejun Heo Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/asm-generic/topology.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/include/asm-generic/topology.h +++ b/include/asm-generic/topology.h @@ -48,7 +48,11 @@ #define parent_node(node) ((void)(node),0) #endif #ifndef cpumask_of_node -#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #ifdef CONFIG_NEED_MULTIPLE_NODES +#define cpumask_of_node(node) ((node) == 0 ? cpu_online_mask : cpu_none_mask) + #else +#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #endif #endif #ifndef pcibus_to_node #define pcibus_to_node(bus)((void)(bus), -1)
[PATCH 4.4 10/16] wl1251: add a missing spin_lock_init()
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Cong Wang commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ti/wl1251/main.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1567,6 +1567,7 @@ struct ieee80211_hw *wl1251_alloc_hw(voi wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE;
[PATCH 4.4 16/16] crypto: algif_skcipher - only call put_page on referenced and used pages
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Stephan Mueller
commit 445a582738de6802669aeed9c33ca406c23c3b1f upstream.
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface.
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/algif_skcipher.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -86,8 +86,13 @@ static void skcipher_free_async_sgls(str
}
sgl = sreq->tsg;
n = sg_nents(sgl);
- for_each_sg(sgl, sg, n, i)
- put_page(sg_page(sg));
+ for_each_sg(sgl, sg, n, i) {
+ struct page *page = sg_page(sg);
+
+ /* some SGs may not have a page mapped */
+ if (page && atomic_read(&page->_count))
+ put_page(page);
+ }
kfree(sreq->tsg);
}
[PATCH 4.4 14/16] kvm: arm/arm64: Force reading uncached stage2 PGD
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Suzuki K Poulose
commit 2952a6070e07ebdd5896f1f5b861acad677caded upstream.
Make sure we don't use a cached value of the KVM stage2 PGD while
resetting the PGD.
Cc: Marc Zyngier
Signed-off-by: Suzuki K Poulose
Reviewed-by: Christoffer Dall
Signed-off-by: Christoffer Dall
Signed-off-by: Suzuki K Poulose
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/kvm/mmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -833,7 +833,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm
spin_lock(&kvm->mmu_lock);
if (kvm->arch.pgd) {
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
- pgd = kvm->arch.pgd;
+ pgd = READ_ONCE(kvm->arch.pgd);
hwpgd = kvm_get_hwpgd(kvm);
kvm->arch.pgd = NULL;
}
[PATCH 4.4 00/16] 4.4.87-stable review
This is the start of the stable review cycle for the 4.4.87 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Sep 7 07:08:53 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.87-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.4.87-rc1 Stephan Mueller crypto: algif_skcipher - only call put_page on referenced and used pages Oleg Nesterov epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove() Suzuki K Poulose kvm: arm/arm64: Force reading uncached stage2 PGD Suzuki K Poulose kvm: arm/arm64: Fix race in resetting stage2 PGD Xiangliang.Yu drm/ttm: Fix accounting error when fail to get pages for pool Vladis Dronov xfrm: policy: check policy direction value Cong Wang wl1251: add a missing spin_lock_init() Steve French CIFS: remove endian related sparse warning Pavel Shilovsky CIFS: Fix maximum SMB2 header size Ben Hutchings alpha: uapi: Add support for __SANE_USERSPACE_TYPES__ Waiman Long cpuset: Fix incorrect memory_pressure control file mapping Tejun Heo cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs Yan, Zheng ceph: fix readpage from fscache Stephen Douthit i2c: ismt: Return EMSGSIZE for block reads with bogus length Stephen Douthit i2c: ismt: Don't duplicate the receive length for block reads James Hogan irqchip: mips-gic: SYNC after enabling GIC region - Diffstat: Makefile | 4 ++-- arch/alpha/include/asm/types.h| 2 +- arch/alpha/include/uapi/asm/types.h | 12 +++- arch/arm/kvm/mmu.c| 23 +++--- crypto/algif_skcipher.c | 9 +++-- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- drivers/i2c/busses/i2c-ismt.c | 6 -- drivers/irqchip/irq-mips-gic.c| 5 - drivers/net/wireless/ti/wl1251/main.c | 1 + fs/ceph/addr.c| 24 ++- fs/ceph/cache.c | 12 +++- fs/cifs/dir.c | 2 +- fs/cifs/smb2pdu.h | 4 ++-- fs/eventpoll.c| 37 +++ include/asm-generic/topology.h| 6 +- kernel/cpuset.c | 1 + net/xfrm/xfrm_policy.c| 6 ++ 17 files changed, 100 insertions(+), 56 deletions(-)
Re: Support for BQ28Z610 Battery Monitor IC
On 04/09/2017 15:53, rajender.re...@stesalit.in wrote:
Dear Rodolfo Giometti,
As discussed please find attached patch.
Please let me know if you need more details.
It looks OK to me... however:
- rewrite the patch's title as "power bq27xxx_battery: add support for BQ28Z610
battery monitor IC"
- align the "=" characters as follow:
+ [BQ28Z610] = {
+ [BQ27XXX_REG_CTRL] = 0x00,
+ [BQ27XXX_REG_TEMP] = 0x06,
+ [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_VOLT] = 0x08,
...
Then send the patch to the mail list or maintainers ad described into the
MAINTAINERS file and adding me in Cc.
Good job! :-)
Ciao,
Rodolfo
--
HCE Engineering e-mail: giome...@hce-engineering.it
GNU/Linux Solutions giome...@enneenne.com
Linux Device Driver giome...@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
Cosino Project - the quick prototyping embedded system - www.cosino.it
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
[PATCH 4.4 07/16] alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.
This fixes compiler errors in perf such as:
tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long
unsigned int', but argument 6 has type '__u64 {aka long unsigned int}'
[-Werror=format=]
snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
^
Signed-off-by: Ben Hutchings
Tested-by: Michael Cree
Signed-off-by: Matt Turner
Signed-off-by: Greg Kroah-Hartman
---
arch/alpha/include/asm/types.h |2 +-
arch/alpha/include/uapi/asm/types.h | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/arch/alpha/include/asm/types.h
+++ b/arch/alpha/include/asm/types.h
@@ -1,6 +1,6 @@
#ifndef _ALPHA_TYPES_H
#define _ALPHA_TYPES_H
-#include
+#include
#endif /* _ALPHA_TYPES_H */
--- a/arch/alpha/include/uapi/asm/types.h
+++ b/arch/alpha/include/uapi/asm/types.h
@@ -9,8 +9,18 @@
* need to be careful to avoid a name clashes.
*/
-#ifndef __KERNEL__
+/*
+ * This is here because we used to use l64 for alpha
+ * and we don't want to impact user mode with our change to ll64
+ * in the kernel.
+ *
+ * However, some user programs are fine with this. They can
+ * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
+ */
+#if !defined(__SANE_USERSPACE_TYPES__) && !defined(__KERNEL__)
#include
+#else
+#include
#endif
#endif /* _UAPI_ALPHA_TYPES_H */
[PATCH 4.9 02/18] i2c: ismt: Dont duplicate the receive length for block reads
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -341,8 +341,8 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: - memcpy(&data->block[1], dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes; + memcpy(data->block, dma_buffer, desc->rxbytes); + data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 4.9 00/18] 4.9.48-stable review
This is the start of the stable review cycle for the 4.9.48 release. There are 18 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Sep 7 07:09:06 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.48-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.9.48-rc1 Oleg Nesterov epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove() Suzuki K Poulose kvm: arm/arm64: Force reading uncached stage2 PGD Xiangliang.Yu drm/ttm: Fix accounting error when fail to get pages for pool Vladis Dronov xfrm: policy: check policy direction value Stephan Mueller lib/mpi: kunmap after finishing accessing buffer Cong Wang wl1251: add a missing spin_lock_init() Steve French CIFS: remove endian related sparse warning Pavel Shilovsky CIFS: Fix maximum SMB2 header size Ben Hutchings alpha: uapi: Add support for __SANE_USERSPACE_TYPES__ Waiman Long cpuset: Fix incorrect memory_pressure control file mapping Tejun Heo cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs Yan, Zheng ceph: fix readpage from fscache Mel Gorman mm, madvise: ensure poisoned pages are removed from per-cpu lists Eric Biggers mm, uprobes: fix multiple free of ->uprobes_state.xol_area Stephan Mueller crypto: algif_skcipher - only call put_page on referenced and used pages Stephen Douthit i2c: ismt: Return EMSGSIZE for block reads with bogus length Stephen Douthit i2c: ismt: Don't duplicate the receive length for block reads James Hogan irqchip: mips-gic: SYNC after enabling GIC region - Diffstat: Makefile | 4 ++-- arch/alpha/include/asm/types.h| 2 +- arch/alpha/include/uapi/asm/types.h | 12 +- arch/arm/kvm/mmu.c| 2 +- crypto/algif_skcipher.c | 9 ++-- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- drivers/i2c/busses/i2c-ismt.c | 6 +++-- drivers/irqchip/irq-mips-gic.c| 5 - drivers/net/wireless/ti/wl1251/main.c | 1 + fs/ceph/addr.c| 24 fs/ceph/cache.c | 12 +++--- fs/cifs/dir.c | 2 +- fs/cifs/smb2pdu.h | 4 ++-- fs/eventpoll.c| 42 ++- include/asm-generic/topology.h| 6 - kernel/cpuset.c | 1 + kernel/events/uprobes.c | 2 -- kernel/fork.c | 8 +++ lib/mpi/mpicoder.c| 4 +++- mm/madvise.c | 7 ++ net/xfrm/xfrm_policy.c| 6 + 21 files changed, 109 insertions(+), 52 deletions(-)
[PATCH 4.9 03/18] i2c: ismt: Return EMSGSIZE for block reads with bogus length
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit ba201c4f5ebe13d7819081756378777d8153f23e upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -341,8 +341,10 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: + if (desc->rxbytes != dma_buffer[0] + 1) + return -EMSGSIZE; + memcpy(data->block, dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 4.9 14/18] lib/mpi: kunmap after finishing accessing buffer
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Stephan Mueller
commit dea3eb8b452e36cf2dd572b0a797915ccf452ae6 upstream.
Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed
to *buff. The current code calls sg_miter_stop (and thus kunmap) on the
SG entry before the last access of *buff.
The patch moves the sg_miter_stop call after the last access to *buff to
ensure that the memory pointed to by *buff is still mapped.
Fixes: 4816c9406430 ("lib/mpi: Fix SG miter leak")
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
lib/mpi/mpicoder.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -364,11 +364,11 @@ MPI mpi_read_raw_from_sgl(struct scatter
}
miter.consumed = lzeros;
- sg_miter_stop(&miter);
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
+ sg_miter_stop(&miter);
pr_info("MPI: mpi too large (%u bits)\n", nbits);
return NULL;
}
@@ -376,6 +376,8 @@ MPI mpi_read_raw_from_sgl(struct scatter
if (nbytes > 0)
nbits -= count_leading_zeros(*buff) - (BITS_PER_LONG - 8);
+ sg_miter_stop(&miter);
+
nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB);
val = mpi_alloc(nlimbs);
if (!val)
[PATCH 4.12 11/27] mm, madvise: ensure poisoned pages are removed from per-cpu lists
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Mel Gorman
commit c461ad6a63b37ba74632e90c063d14823c884247 upstream.
Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed
and bisected it to the commit 479f854a207c ("mm, page_alloc: defer
debugging checks of pages allocated from the PCP").
The problem is that a page that was poisoned with madvise() is reused.
The commit removed a check that would trigger if DEBUG_VM was enabled
but re-enabling the check only fixes the problem as a side-effect by
printing a bad_page warning and recovering.
The root of the problem is that an madvise() can leave a poisoned page
on the per-cpu list. This patch drains all per-cpu lists after pages
are poisoned so that they will not be reused. Wendy reports that the
test case in question passes with this patch applied. While this could
be done in a targeted fashion, it is over-complicated for such a rare
operation.
Link:
http://lkml.kernel.org/r/20170828133414.7qro57jbepdcy...@techsingularity.net
Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated
from the PCP")
Signed-off-by: Mel Gorman
Reported-by: Wang, Wendy
Tested-by: Wang, Wendy
Acked-by: David Rientjes
Acked-by: Vlastimil Babka
Cc: "Hansen, Dave"
Cc: "Luck, Tony"
Cc: Naoya Horiguchi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/madvise.c |6 ++
1 file changed, 6 insertions(+)
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -610,6 +610,7 @@ static int madvise_inject_error(int beha
unsigned long start, unsigned long end)
{
struct page *page;
+ struct zone *zone;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -643,6 +644,11 @@ static int madvise_inject_error(int beha
if (ret)
return ret;
}
+
+ /* Ensure that all poisoned pages are removed from per-cpu lists */
+ for_each_populated_zone(zone)
+ drain_all_pages(zone);
+
return 0;
}
#endif
[PATCH 4.12 03/27] irqchip: mips-gic: SYNC after enabling GIC region
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit 2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream.
A SYNC is required between enabling the GIC region and actually trying
to use it, even if the first access is a read, otherwise its possible
depending on the timing (and in my case depending on the precise
alignment of certain kernel code) to hit CM bus errors on that first
access.
Add the SYNC straight after setting the GIC base.
[paul.bur...@imgtec.com:
Changes later in this series increase our likelihood of hitting this
by reducing the amount of code that runs between enabling the GIC &
accessing it.]
Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support")
Signed-off-by: James Hogan
Signed-off-by: Paul Burton
Acked-by: Marc Zyngier
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17019/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-mips-gic.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -1022,8 +1022,11 @@ static int __init gic_of_init(struct dev
gic_len = resource_size(&res);
}
- if (mips_cm_present())
+ if (mips_cm_present()) {
write_gcr_gic_base(gic_base | CM_GCR_GIC_BASE_GICEN_MSK);
+ /* Ensure GIC region is enabled before trying to access it */
+ __sync();
+ }
gic_present = true;
__gic_init(gic_base, gic_len, cpu_vec, 0, node);
[PATCH 4.12 09/27] crypto: algif_skcipher - only call put_page on referenced and used pages
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Stephan Mueller
commit 445a582738de6802669aeed9c33ca406c23c3b1f upstream.
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface.
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/algif_skcipher.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -87,8 +87,13 @@ static void skcipher_free_async_sgls(str
}
sgl = sreq->tsg;
n = sg_nents(sgl);
- for_each_sg(sgl, sg, n, i)
- put_page(sg_page(sg));
+ for_each_sg(sgl, sg, n, i) {
+ struct page *page = sg_page(sg);
+
+ /* some SGs may not have a page mapped */
+ if (page && page_ref_count(page))
+ put_page(page);
+ }
kfree(sreq->tsg);
}
[PATCH 4.12 07/27] i2c: ismt: Dont duplicate the receive length for block reads
4.12-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -341,8 +341,8 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: - memcpy(&data->block[1], dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes; + memcpy(data->block, dma_buffer, desc->rxbytes); + data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 4.12 23/27] xfrm: policy: check policy direction value
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Vladis Dronov
commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint
address(es)")
Reported-by: "bo Zhang"
Signed-off-by: Vladis Dronov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_policy.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3301,9 +3301,15 @@ int xfrm_migrate(const struct xfrm_selec
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
+ /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
+ if (dir >= XFRM_POLICY_MAX) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
[PATCH 4.12 13/27] cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
4.12-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit b339752d054fb32863418452dff350a1086885b1 upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by: Tejun Heo Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/asm-generic/topology.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/include/asm-generic/topology.h +++ b/include/asm-generic/topology.h @@ -48,7 +48,11 @@ #define parent_node(node) ((void)(node),0) #endif #ifndef cpumask_of_node -#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #ifdef CONFIG_NEED_MULTIPLE_NODES +#define cpumask_of_node(node) ((node) == 0 ? cpu_online_mask : cpu_none_mask) + #else +#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #endif #endif #ifndef pcibus_to_node #define pcibus_to_node(bus)((void)(bus), -1)
[PATCH 4.12 21/27] mmc: sdhci-xenon: add set_power callback
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Zhoujie Wu
commit 99c14fc360dbbb583a03ab985551b12b5c5ca4f1 upstream.
Xenon sdh controller requests proper SD bus voltage select
bits programmed even with vmmc power supply. Any reserved
value(100b-000b) programmed in this field will lead to controller
ignore SD bus power bit and keep its value at zero.
Add set_power callback to handle this.
Signed-off-by: Zhoujie Wu
Acked-by: Adrian Hunter
Tested-by: Gregory CLEMENT
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core
functionality")
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-xenon.c | 19 +++
1 file changed, 19 insertions(+)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -210,8 +210,27 @@ static void xenon_set_uhs_signaling(stru
sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
}
+static void xenon_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+ u8 pwr = host->pwr;
+
+ sdhci_set_power_noreg(host, mode, vdd);
+
+ if (host->pwr == pwr)
+ return;
+
+ if (host->pwr == 0)
+ vdd = 0;
+
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+}
+
static const struct sdhci_ops sdhci_xenon_ops = {
.set_clock = sdhci_set_clock,
+ .set_power = xenon_set_power,
.set_bus_width = sdhci_set_bus_width,
.reset = xenon_reset,
.set_uhs_signaling = xenon_set_uhs_signaling,
[PATCH 4.12 14/27] cpuset: Fix incorrect memory_pressure control file mapping
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Waiman Long
commit 1c08c22c874ac88799cab1f78c40f46110274915 upstream.
The memory_pressure control file was incorrectly set up without
a private value (0, by default). As a result, this control
file was treated like memory_migrate on read. By adding back the
FILE_MEMORY_PRESSURE private value, the correct memory pressure value
will be returned.
Signed-off-by: Waiman Long
Signed-off-by: Tejun Heo
Fixes: 7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE")
Signed-off-by: Greg Kroah-Hartman
---
kernel/cgroup/cpuset.c |1 +
1 file changed, 1 insertion(+)
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1907,6 +1907,7 @@ static struct cftype files[] = {
{
.name = "memory_pressure",
.read_u64 = cpuset_read_u64,
+ .private = FILE_MEMORY_PRESSURE,
},
{
[PATCH 4.12 15/27] alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.
This fixes compiler errors in perf such as:
tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long
unsigned int', but argument 6 has type '__u64 {aka long unsigned int}'
[-Werror=format=]
snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
^
Signed-off-by: Ben Hutchings
Tested-by: Michael Cree
Signed-off-by: Matt Turner
Signed-off-by: Greg Kroah-Hartman
---
arch/alpha/include/asm/types.h |2 +-
arch/alpha/include/uapi/asm/types.h | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/arch/alpha/include/asm/types.h
+++ b/arch/alpha/include/asm/types.h
@@ -1,6 +1,6 @@
#ifndef _ALPHA_TYPES_H
#define _ALPHA_TYPES_H
-#include
+#include
#endif /* _ALPHA_TYPES_H */
--- a/arch/alpha/include/uapi/asm/types.h
+++ b/arch/alpha/include/uapi/asm/types.h
@@ -9,8 +9,18 @@
* need to be careful to avoid a name clashes.
*/
-#ifndef __KERNEL__
+/*
+ * This is here because we used to use l64 for alpha
+ * and we don't want to impact user mode with our change to ll64
+ * in the kernel.
+ *
+ * However, some user programs are fine with this. They can
+ * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
+ */
+#if !defined(__SANE_USERSPACE_TYPES__) && !defined(__KERNEL__)
#include
+#else
+#include
#endif
#endif /* _UAPI_ALPHA_TYPES_H */
[PATCH 4.12 17/27] CIFS: remove endian related sparse warning
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
Recent patch had an endian warning ie
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Signed-off-by: Steve French
CC: Ronnie Sahlberg
Acked-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -205,7 +205,7 @@ check_name(struct dentry *direntry, stru
int i;
if (unlikely(direntry->d_name.len >
-tcon->fsAttrInfo.MaxPathNameComponentLength))
+le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
return -ENAMETOOLONG;
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)) {
[PATCH 4.12 19/27] drm/vmwgfx: Fix F26 Wayland screen update issue
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Sinclair Yeh
commit 021aba761f2a6c12158afb9993524c300c01fae2 upstream.
vmwgfx currently cannot support non-blocking commit because when
vmw_*_crtc_page_flip is called, drm_atomic_nonblocking_commit()
schedules the update on a thread. This means vmw_*_crtc_page_flip
cannot rely on the new surface being bound before the subsequent
dirty and flush operations happen.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
Reviewed-by: Charmaine Lee
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1567,10 +1567,34 @@ vmw_kms_atomic_check_modeset(struct drm_
}
+/**
+ * vmw_kms_atomic_commit - Perform an atomic state commit
+ *
+ * @dev: DRM device
+ * @state: the driver state object
+ * @nonblock: Whether nonblocking behaviour is requested
+ *
+ * This is a simple wrapper around drm_atomic_helper_commit() for
+ * us to clear the nonblocking value.
+ *
+ * Nonblocking commits currently cause synchronization issues
+ * for vmwgfx.
+ *
+ * RETURNS
+ * Zero for success or negative error code on failure.
+ */
+int vmw_kms_atomic_commit(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool nonblock)
+{
+ return drm_atomic_helper_commit(dev, state, false);
+}
+
+
static const struct drm_mode_config_funcs vmw_kms_funcs = {
.fb_create = vmw_kms_fb_create,
.atomic_check = vmw_kms_atomic_check_modeset,
- .atomic_commit = drm_atomic_helper_commit,
+ .atomic_commit = vmw_kms_atomic_commit,
};
static int vmw_kms_generic_present(struct vmw_private *dev_priv,
[PATCH 4.12 22/27] lib/mpi: kunmap after finishing accessing buffer
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Stephan Mueller
commit dea3eb8b452e36cf2dd572b0a797915ccf452ae6 upstream.
Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed
to *buff. The current code calls sg_miter_stop (and thus kunmap) on the
SG entry before the last access of *buff.
The patch moves the sg_miter_stop call after the last access to *buff to
ensure that the memory pointed to by *buff is still mapped.
Fixes: 4816c9406430 ("lib/mpi: Fix SG miter leak")
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
lib/mpi/mpicoder.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -364,11 +364,11 @@ MPI mpi_read_raw_from_sgl(struct scatter
}
miter.consumed = lzeros;
- sg_miter_stop(&miter);
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
+ sg_miter_stop(&miter);
pr_info("MPI: mpi too large (%u bits)\n", nbits);
return NULL;
}
@@ -376,6 +376,8 @@ MPI mpi_read_raw_from_sgl(struct scatter
if (nbytes > 0)
nbits -= count_leading_zeros(*buff) - (BITS_PER_LONG - 8);
+ sg_miter_stop(&miter);
+
nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB);
val = mpi_alloc(nlimbs);
if (!val)
[PATCH 4.12 20/27] wl1251: add a missing spin_lock_init()
4.12-stable review patch. If anyone has any objections, please let me know. -- From: Cong Wang commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ti/wl1251/main.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(voi wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE;
[PATCH] media: leds: as3645a: add V4L2_FLASH_LED_CLASS depdendency
We get a link error when V4L2_FLASH_LED_CLASS=m and AS3645A is built-in:
drivers/leds/leds-as3645a.o: In function `as3645a_v4l2_setup':
leds-as3645a.c:(.text+0x258): undefined reference to `v4l2_flash_init'
leds-as3645a.c:(.text+0x284): undefined reference to `v4l2_flash_indicator_init'
leds-as3645a.c:(.text+0x2a4): undefined reference to `v4l2_flash_release'
drivers/leds/leds-as3645a.o: In function `as3645a_remove':
leds-as3645a.c:(.text+0x784): undefined reference to `v4l2_flash_release'
This adds the same Kconfig dependency that the other V4L2 flash
drivers in drivers/leds use, to avoid that broken configuration.
Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver")
Signed-off-by: Arnd Bergmann
---
drivers/leds/Kconfig | 1 +
1 file changed, 1 insertion(+)
The patch that caused the problem is currently in the v4l git tree,
rather than the leds tree. Please merge this through an appropriate
path, either v4l or led, depending on the timing.
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 0bf022bcb6ac..52ea34e337cd 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -61,6 +61,7 @@ config LEDS_AAT1290
config LEDS_AS3645A
tristate "AS3645A LED flash controller support"
depends on I2C && LEDS_CLASS_FLASH
+ depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
help
Enable LED flash class support for AS3645A LED flash
controller. V4L2 flash API is provided as well if
--
2.9.0
[PATCH 4.12 16/27] CIFS: Fix maximum SMB2 header size
4.12-stable review patch. If anyone has any objections, please let me know. -- From: Pavel Shilovsky commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/cifs/smb2pdu.h +++ b/fs/cifs/smb2pdu.h @@ -84,8 +84,8 @@ #define NUMBER_OF_SMB2_COMMANDS0x0013 -/* BB FIXME - analyze following length BB */ -#define MAX_SMB2_HDR_SIZE 0x78 /* 4 len + 64 hdr + (2*24 wct) + 2 bct + 2 pad */ +/* 4 len + 52 transform hdr + 64 hdr + 56 create rsp */ +#define MAX_SMB2_HDR_SIZE 0x00b0 #define SMB2_PROTO_NUMBER cpu_to_le32(0x424d53fe) #define SMB2_TRANSFORM_PROTO_NUM cpu_to_le32(0x424d53fd)
Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early
On Tue 05-09-17 11:59:36, Anshuman Khandual wrote:
[...]
> > @@ -1634,43 +1634,25 @@ static int __ref __offline_pages(unsigned long
> > start_pfn,
> >
> > pfn = start_pfn;
> > expire = jiffies + timeout;
> > - drain = 0;
> > - retry_max = 5;
> > repeat:
> > /* start memory hot removal */
> > - ret = -EAGAIN;
> > + ret = -EBUSY;
> > if (time_after(jiffies, expire))
> > goto failed_removal;
> > ret = -EINTR;
> > if (signal_pending(current))
> > goto failed_removal;
> > - ret = 0;
> > - if (drain) {
> > - lru_add_drain_all_cpuslocked();
> > - cond_resched();
> > - drain_all_pages(zone);
> > - }
>
> Why we had this condition before that only when we fail in migration
> later in do_migrate_range function, drain the lru lists in the next
> attempt. Why not from the first attempt itself ? Just being curious.
I can only guess but draining used to invoke IPIs and that is really
costly so an optimistic attempt could try without draining and do that
only if the migration fails. Now that we have it all done in WQ context
there shouldn't be any reason to optimize for draining.
--
Michal Hocko
SUSE Labs
Re: [PATCH] IRQ, cpu-hotplug: Fix a race between CPU hotplug and IRQ desc alloc/free
On Tue, 5 Sep 2017, Huang, Ying wrote: > Thomas Gleixner writes: > > + /* Interrupts are moved away from the dying cpu, reenable alloc/free */ > > + irq_unlock_sparse(); > > + > > I don't understand this. It appears that irq_migrate_all_off_this_cpu() > is called in take_cpu_down() which has sparse_irq_lock held already. You're right. I was looking at the wrong place. Thanks, tglx
[PATCH 4.12 18/27] dm mpath: do not lock up a CPU with requeuing activity
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Bart Van Assche
commit 1c23484c355ec360ca2f37914f8a4802c6baeead upstream.
When using the block layer in single queue mode, get_request()
returns ERR_PTR(-EAGAIN) if the queue is dying and the REQ_NOWAIT
flag has been passed to get_request(). Avoid that the kernel
reports soft lockup complaints in this case due to continuous
requeuing activity.
Fixes: 7083abbbf ("dm mpath: avoid that path removal can trigger an infinite
loop")
Signed-off-by: Bart Van Assche
Tested-by: Laurence Oberman
Reviewed-by: Christoph Hellwig
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-mpath.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -504,7 +504,6 @@ static int multipath_clone_and_map(struc
if (queue_dying) {
atomic_inc(&m->pg_init_in_progress);
activate_or_offline_path(pgpath);
- return DM_MAPIO_REQUEUE;
}
return DM_MAPIO_DELAY_REQUEUE;
}
[PATCH 4.12 25/27] nvme: fix the definition of the doorbell buffer config support bit
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Changpeng Liu
commit 223694b9ae8bfba99f3528d49d07a740af6ff95a upstream.
NVMe 1.3 specification defines the Optional Admin Command Support feature
flags, bit 8 set to '1' then the controller supports the Doorbell Buffer
Config command. Bit 7 is used for Virtualization Mangement command.
Signed-off-by: Changpeng Liu
Reviewed-by: Sagi Grimberg
Reviewed-by: Max Gurtovoy
Reviewed-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
Fixes: f9f38e33 ("nvme: improve performance for virtual NVMe devices")
Signed-off-by: Greg Kroah-Hartman
---
include/linux/nvme.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/nvme.h
+++ b/include/linux/nvme.h
@@ -245,7 +245,7 @@ enum {
NVME_CTRL_ONCS_WRITE_ZEROES = 1 << 3,
NVME_CTRL_VWC_PRESENT = 1 << 0,
NVME_CTRL_OACS_SEC_SUPP = 1 << 0,
- NVME_CTRL_OACS_DBBUF_SUPP = 1 << 7,
+ NVME_CTRL_OACS_DBBUF_SUPP = 1 << 8,
};
struct nvme_lbaf {
[PATCH 4.12 26/27] drm/nouveau/i2c/gf119-: add support for address-only transactions
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Skeggs
commit 13a86519202c5d119d83640d6f781f3181205d2c upstream.
Since switching the I2C-over-AUX helpers, there have been regressions on
some display combinations due to us not having support for "address only"
transactions.
This commits enables support for them for GF119 and newer.
Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.
Signed-off-by: Ben Skeggs
Cc: Ilia Mirkin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_connector.c|2 -
drivers/gpu/drm/nouveau/nv50_display.c | 13 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild |1
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c |4 ++
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h |6 +++
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 30 +++---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c | 35 +
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c |5 +--
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgf119.c |4 +-
9 files changed, 81 insertions(+), 19 deletions(-)
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1155,8 +1155,6 @@ nouveau_connector_aux_xfer(struct drm_dp
return -ENODEV;
if (WARN_ON(msg->size > 16))
return -E2BIG;
- if (msg->size == 0)
- return msg->size;
ret = nvkm_i2c_aux_acquire(aux);
if (ret)
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -3618,15 +3618,24 @@ nv50_sor_create(struct drm_connector *co
drm_mode_connector_attach_encoder(connector, encoder);
if (dcbe->type == DCB_OUTPUT_DP) {
+ struct nv50_disp *disp = nv50_disp(encoder->dev);
struct nvkm_i2c_aux *aux =
nvkm_i2c_aux_find(i2c, dcbe->i2c_index);
if (aux) {
- nv_encoder->i2c = &nv_connector->aux.ddc;
+ if (disp->disp->oclass < GF110_DISP) {
+ /* HW has no support for address-only
+* transactions, so we're required to
+* use custom I2C-over-AUX code.
+*/
+ nv_encoder->i2c = &aux->i2c;
+ } else {
+ nv_encoder->i2c = &nv_connector->aux.ddc;
+ }
nv_encoder->aux = aux;
}
/*TODO: Use DP Info Table to check for support. */
- if (nv50_disp(encoder->dev)->disp->oclass >= GF110_DISP) {
+ if (disp->disp->oclass >= GF110_DISP) {
ret = nv50_mstm_new(nv_encoder, &nv_connector->aux, 16,
nv_connector->base.base.id,
&nv_encoder->dp.mstm);
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
@@ -25,6 +25,7 @@ nvkm-y += nvkm/subdev/i2c/bit.o
nvkm-y += nvkm/subdev/i2c/aux.o
nvkm-y += nvkm/subdev/i2c/auxg94.o
+nvkm-y += nvkm/subdev/i2c/auxgf119.o
nvkm-y += nvkm/subdev/i2c/auxgm200.o
nvkm-y += nvkm/subdev/i2c/anx9805.o
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
@@ -117,6 +117,10 @@ int
nvkm_i2c_aux_xfer(struct nvkm_i2c_aux *aux, bool retry, u8 type,
u32 addr, u8 *data, u8 *size)
{
+ if (!*size && !aux->func->address_only) {
+ AUX_ERR(aux, "address-only transaction dropped");
+ return -ENOSYS;
+ }
return aux->func->xfer(aux, retry, type, addr, data, size);
}
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h
@@ -3,6 +3,7 @@
#include "pad.h"
struct nvkm_i2c_aux_func {
+ bool address_only;
int (*xfer)(struct nvkm_i2c_aux *, bool retry, u8 type,
u32 addr, u8 *data, u8 *size);
int (*lnk_ctl)(struct nvkm_i2c_aux *, int link_nr, int link_bw,
@@ -17,7 +18,12 @@ void nvkm_i2c_aux_del(struct nvkm_i2c_au
int nvkm_i2c_aux_xfer(struct nvkm_i2c_aux *, bool retry, u8 type,
u32 addr, u8 *data, u8 *size);
+int g94_i2c_aux_new_(const struct nvkm_i2c_aux_func *, struct nvkm_i2c_pad *,
+int, u8, struct nvkm_i2c_aux **);
+
int g94_i2c_aux_new(struct nvkm_i2c_pad *, int, u8, struct nvkm_i2c_aux **);
+int g94_i2c_aux_xfer(struct nvkm_i2c_aux *, bool, u8, u32, u8 *, u8 *);
+int gf119_i2c_aux_new(struct nvkm_i2c_pad *, int, u8, struct nvkm_i2c_aux **);
int gm200_i2c_aux_new(struct nvkm_i2c_pad *, int, u8, struct nvkm_i2c_aux **);
#define AUX_MSG(b,l,f,a...) do {
Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage
On Tue, 5 Sep 2017, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 915f3e3f76c05b2da93c4cc278eebc2d9219d9f4 > Author: Thomas Gleixner > AuthorDate: Sat Feb 25 11:27:37 2017 +0100 > Commit: Linus Torvalds > CommitDate: Sat Feb 25 09:48:16 2017 -0800 > > mac80211_hwsim: Replace bogus hrtimer clockid > > mac80211_hwsim initializes a hrtimer with clockid CLOCK_MONOTONIC_RAW. > That's not supported. > > Use CLOCK_MONOTNIC instead. Sorry, no. That bisect is completely bogus. The commit in question merily replaces the unsupported clockid with a valid one. Thanks, tglx
[PATCH 4.12 04/27] Input: synaptics - fix device info appearing different on reconnect
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Anthony Martin
commit 3f9db52dc87b003a1732f3e03f7f5fc8701ef4ad upstream.
User-modified input settings no longer survive a suspend/resume cycle.
Starting with 4.12, the touchpad is reinitialized on every reconnect
because the hardware appears to be different. This can be reproduced
by running the following as root:
echo -n reconnect >/sys/devices/platform/i8042/serio1/drvctl
A line like the following will show up in dmesg:
[30378.295794] psmouse serio1: synaptics: hardware appears to be
different: id(149271-149271), model(114865-114865),
caps(d047b3-d047b1), ext(b4-b4).
Note the single bit difference in caps: bit 1 (SYN_CAP_MULTIFINGER).
This happens because we modify our stored copy of the device info
capabilities when we enable advanced gesture mode but this change is
not reflected in the actual hardware capabilities.
It worked in the past because synaptics_query_hardware used to modify
the stored synaptics_device_info struct instead of filling in a new
one, as it does now.
Fix it by no longer faking the SYN_CAP_MULTIFINGER bit when setting
advanced gesture mode. This necessitated a small refactoring.
Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate
structure")
Signed-off-by: Anthony Martin
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/mouse/synaptics.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -535,16 +535,17 @@ static void synaptics_apply_quirks(struc
}
}
+static bool synaptics_has_agm(struct synaptics_data *priv)
+{
+ return (SYN_CAP_ADV_GESTURE(priv->info.ext_cap_0c) ||
+ SYN_CAP_IMAGE_SENSOR(priv->info.ext_cap_0c));
+}
+
static int synaptics_set_advanced_gesture_mode(struct psmouse *psmouse)
{
static u8 param = 0xc8;
- struct synaptics_data *priv = psmouse->private;
int error;
- if (!(SYN_CAP_ADV_GESTURE(priv->info.ext_cap_0c) ||
- SYN_CAP_IMAGE_SENSOR(priv->info.ext_cap_0c)))
- return 0;
-
error = psmouse_sliced_command(psmouse, SYN_QUE_MODEL);
if (error)
return error;
@@ -553,9 +554,6 @@ static int synaptics_set_advanced_gestur
if (error)
return error;
- /* Advanced gesture mode also sends multi finger data */
- priv->info.capabilities |= BIT(1);
-
return 0;
}
@@ -578,7 +576,7 @@ static int synaptics_set_mode(struct psm
if (error)
return error;
- if (priv->absolute_mode) {
+ if (priv->absolute_mode && synaptics_has_agm(priv)) {
error = synaptics_set_advanced_gesture_mode(psmouse);
if (error) {
psmouse_err(psmouse,
@@ -766,9 +764,7 @@ static int synaptics_parse_hw_state(cons
((buf[0] & 0x04) >> 1) |
((buf[3] & 0x04) >> 2));
- if ((SYN_CAP_ADV_GESTURE(priv->info.ext_cap_0c) ||
- SYN_CAP_IMAGE_SENSOR(priv->info.ext_cap_0c)) &&
- hw->w == 2) {
+ if (synaptics_has_agm(priv) && hw->w == 2) {
synaptics_parse_agm(buf, priv, hw);
return 1;
}
@@ -1033,6 +1029,15 @@ static void synaptics_image_sensor_proce
synaptics_report_mt_data(psmouse, sgm, num_fingers);
}
+static bool synaptics_has_multifinger(struct synaptics_data *priv)
+{
+ if (SYN_CAP_MULTIFINGER(priv->info.capabilities))
+ return true;
+
+ /* Advanced gesture mode also sends multi finger data */
+ return synaptics_has_agm(priv);
+}
+
/*
* called for each full received packet from the touchpad
*/
@@ -1079,7 +1084,7 @@ static void synaptics_process_packet(str
if (SYN_CAP_EXTENDED(info->capabilities)) {
switch (hw.w) {
case 0 ... 1:
- if (SYN_CAP_MULTIFINGER(info->capabilities))
+ if (synaptics_has_multifinger(priv))
num_fingers = hw.w + 2;
break;
case 2:
@@ -1123,7 +1128,7 @@ static void synaptics_process_packet(str
input_report_abs(dev, ABS_TOOL_WIDTH, finger_width);
input_report_key(dev, BTN_TOOL_FINGER, num_fingers == 1);
- if (SYN_CAP_MULTIFINGER(info->capabilities)) {
+ if (synaptics_has_multifinger(priv)) {
input_report_key(dev, BTN_TOOL_DOUBLETAP, num_fingers == 2);
input_report_key(dev, BTN_TOOL_TRIPLETAP, num_fingers == 3);
}
@@ -1283,7 +1288,7 @@ static void set_input_params(struct psmo
__se
[PATCH 4.12 00/27] 4.12.11-stable review
This is the start of the stable review cycle for the 4.12.11 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Sep 7 07:09:10 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.11-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.12.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.12.11-rc1 Oleg Nesterov epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove() Ben Skeggs drm/nouveau/i2c/gf119-: add support for address-only transactions Changpeng Liu nvme: fix the definition of the doorbell buffer config support bit Xiangliang.Yu drm/ttm: Fix accounting error when fail to get pages for pool Vladis Dronov xfrm: policy: check policy direction value Stephan Mueller lib/mpi: kunmap after finishing accessing buffer Zhoujie Wu mmc: sdhci-xenon: add set_power callback Cong Wang wl1251: add a missing spin_lock_init() Sinclair Yeh drm/vmwgfx: Fix F26 Wayland screen update issue Bart Van Assche dm mpath: do not lock up a CPU with requeuing activity Steve French CIFS: remove endian related sparse warning Pavel Shilovsky CIFS: Fix maximum SMB2 header size Ben Hutchings alpha: uapi: Add support for __SANE_USERSPACE_TYPES__ Waiman Long cpuset: Fix incorrect memory_pressure control file mapping Tejun Heo cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs Yan, Zheng ceph: fix readpage from fscache Mel Gorman mm, madvise: ensure poisoned pages are removed from per-cpu lists Eric Biggers mm, uprobes: fix multiple free of ->uprobes_state.xol_area Stephan Mueller crypto: algif_skcipher - only call put_page on referenced and used pages Stephen Douthit i2c: ismt: Return EMSGSIZE for block reads with bogus length Stephen Douthit i2c: ismt: Don't duplicate the receive length for block reads Ard Biesheuvel crypto: chacha20 - fix handling of chunked input Cameron Gutman Input: xpad - fix PowerA init quirk for some gamepad models Anthony Martin Input: synaptics - fix device info appearing different on reconnect James Hogan irqchip: mips-gic: SYNC after enabling GIC region Arnd Bergmann x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl Mark Rutland arm64: mm: abort uaccess retries upon fatal signal - Diffstat: Makefile | 4 +-- arch/alpha/include/asm/types.h | 2 +- arch/alpha/include/uapi/asm/types.h| 12 ++- arch/arm64/mm/fault.c | 5 ++- arch/x86/include/asm/io.h | 4 +-- crypto/algif_skcipher.c| 9 +++-- crypto/chacha20_generic.c | 9 +++-- drivers/gpu/drm/nouveau/nouveau_connector.c| 2 -- drivers/gpu/drm/nouveau/nv50_display.c | 13 +-- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 4 +++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h | 6 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c | 30 ++-- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c | 35 ++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 5 +-- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgf119.c | 4 +-- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 26 +- drivers/i2c/busses/i2c-ismt.c | 6 ++-- drivers/input/joystick/xpad.c | 24 ++--- drivers/input/mouse/synaptics.c| 35 ++ drivers/irqchip/irq-mips-gic.c | 5 ++- drivers/md/dm-mpath.c | 1 - drivers/mmc/host/sdhci-xenon.c | 19 ++ drivers/net/wireless/ti/wl1251/main.c | 1 + fs/ceph/addr.c | 24 - fs/ceph/cache.c| 12 ++- fs/cifs/dir.c | 2 +- fs/cifs/smb2pdu.h | 4 +-- fs/eventpoll.c | 42 +- include/asm-generic/topology.h | 6 +++- include/linux/nvme.h | 2 +- kernel/cgroup/cpuset.c | 1 + kernel/events/uprobes.c| 2 -- kernel/fork.c
[PATCH 4.12 08/27] i2c: ismt: Return EMSGSIZE for block reads with bogus length
4.12-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit ba201c4f5ebe13d7819081756378777d8153f23e upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -341,8 +341,10 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: + if (desc->rxbytes != dma_buffer[0] + 1) + return -EMSGSIZE; + memcpy(data->block, dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 4.12 06/27] crypto: chacha20 - fix handling of chunked input
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
commit 4de437265eaac18f880d827f8e105b10de9b87a3 upstream.
Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions
to skcipher") ported the existing chacha20 code to use the new skcipher
API, and introduced a bug along the way. Unfortunately, the tcrypt tests
did not catch the error, and it was only found recently by Tobias.
Stefan kindly diagnosed the error, and proposed a fix which is similar
to the one below, with the exception that 'walk.stride' is used rather
than the hardcoded block size. This does not actually matter in this
case, but it's a better example of how to use the skcipher walk API.
Fixes: 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 ...")
Cc: Steffen Klassert
Reported-by: Tobias Brunner
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/chacha20_generic.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/crypto/chacha20_generic.c
+++ b/crypto/chacha20_generic.c
@@ -91,9 +91,14 @@ int crypto_chacha20_crypt(struct skciphe
crypto_chacha20_init(state, ctx, walk.iv);
while (walk.nbytes > 0) {
+ unsigned int nbytes = walk.nbytes;
+
+ if (nbytes < walk.total)
+ nbytes = round_down(nbytes, walk.stride);
+
chacha20_docrypt(state, walk.dst.virt.addr, walk.src.virt.addr,
-walk.nbytes);
- err = skcipher_walk_done(&walk, 0);
+nbytes);
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
}
return err;
[PATCHv7 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong
---
V7:
*Fix Comments. Fix indentation in Makefile
V6:
*Fix Comments. Commit comments need to be discriptive
V5:
*Fix Comments. Remove dem_kfree and bits per symbol
V4:
*No fixes.
V3:
*Changes to fixing drm_simple_pipe
*Used drm_fb_cma_get_gem_addr
V2:
*Adding drm_simple_display_pipe_init
---
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile | 9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 96 +
drivers/gpu/drm/ivip/intel_vip_core.c | 162
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +
drivers/gpu/drm/ivip/intel_vip_of.c | 194 ++
8 files changed, 530 insertions(+)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a8..38a184d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..4162a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..bf2d995
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..c88df23
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,96 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_des
[PATCHv7 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 2620ce7..255f553 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -111,6 +111,12 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y +CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 2.7.4
[PATCHv7 0/3] Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (3): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 84 + arch/arm/configs/socfpga_defconfig | 6 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile | 9 + drivers/gpu/drm/ivip/intel_vip_conn.c | 96 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 162 + drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++ drivers/gpu/drm/ivip/intel_vip_of.c| 194 + 10 files changed, 587 insertions(+), 33 deletions(-) create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c -- 2.7.4
[PATCHv7] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height and memory port width.
The device tree binding only supports the Intel Arria10
devkit and its variants. Vendor name retained as altr.
Signed-off-by: Ong, Hean Loong
---
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
---
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 74 ++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..bf0055d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,74 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Example:
+
+
+ +--+
+ |FPGA |++
+ +-+ +--+ || DP|
++-+| VIP| | DP | +> Connector |
+| || Frame | | Controller | |||
+| D +> Buffer | +--+ |++
+| D || | +--+ |
+| R || | | DP | |
+| |+-+ | Encoder | |
+| || +--+ |
++-++--+
+
+
+framebuffer@10280 {
+compatible = "altr,vip-frame-buffer-2.0";
+reg = <0x0001 0x0280 0x0040>;
+altr,max-width = <1280>;
+altr,max-height = <720>;
+altr,mem-port-width = <128>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+reg = <1>;
+fb_output: endpoint {
+remote-endpoint = <&dp_encoder_input>;
+};
+};
+};
+};
+
--
2.7.4
Re: [PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement
On Tue, Sep 5, 2017 at 12:09 AM, Andreas Färber wrote: > Am 14.05.2017 um 04:24 schrieb Andreas Färber: >> This mini-series adds initial support for the Realtek RTD1295 SoC and >> the Zidoo X9S TV box. >> >> v3 changes #address-cells, #size-cells and ranges. >> >> With these patches CPU0 can be booted with earlycon. >> >> PSCI doesn't work despite present in the vendor device tree; as enable-method >> it instead used a custom "rtk-spin-table" that I sadly have no source code >> of. > > Synology has now published source code for RTD1293/1296. This has > allowed me to narrow the RTD1295 CPU1..3 issue down to two changes in > arch/arm64/kernel/smp_spin_table.c:smp_spin_table_cpu_prepare(): > > 1) writel_relaxed() instead of writeq_relaxed() > 2) ioremap() instead of ioremap_cache() > > Without those changes it hangs in earlycon after this line: > [0.043674] Mountpoint-cache hash table entries: 4096 (order: 3, > 32768 bytes) > > The size difference sounds easy enough - we could introduce an optional > cpu-release-size property to handle this or derive a "spin-table-32bit" > enable-method to that effect. > > The second one appears to be caused by PROT_NORMAL vs. > PROT_DEVICE_nGnRE. Is there any simple check we could do on > cpu-release-addr to choose which MT to use? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=113954c6463d1d80a206e91627ae49711f8b47cd > > Any other ideas? I think we had a similar problem before and concluded that something requiring a write into an MMIO register is simply not a spin-table implementation but something else. Is this simply using a copy of the spin-table code to trigger the actual booting of the secondary CPU? Can you identify the MMIO address? Arnd
[PATCH 4.12 05/27] Input: xpad - fix PowerA init quirk for some gamepad models
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Cameron Gutman
commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 upstream.
The PowerA gamepad initialization quirk worked with the PowerA
wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
that it didn't work for him, even though our gamepads shared the
same vendor and product IDs.
When I initially implemented the PowerA quirk, I wanted to avoid
actually triggering the rumble action during init. My tests showed
that my gamepad would work correctly even if it received a rumble
of 0 intensity, so that's what I went with.
Unfortunately, this apparently isn't true for all models (perhaps
a firmware difference?). This non-working gamepad seems to require
the real magic rumble packet that the Microsoft driver sends, which
actually vibrates the gamepad. To counteract this effect, I still
send the old zero-rumble PowerA quirk packet which cancels the
rumble effect before the motors can spin up enough to vibrate.
[0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867
Reported-by: Kyle Beauchamp
Tested-by: Kyle Beauchamp
Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
Signed-off-by: Cameron Gutman
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/joystick/xpad.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -389,10 +389,21 @@ static const u8 xboxone_hori_init[] = {
};
/*
- * A rumble packet is required for some PowerA pads to start
+ * A specific rumble packet is required for some PowerA pads to start
* sending input reports. One of those pads is (0x24c6:0x543a).
*/
-static const u8 xboxone_zerorumble_init[] = {
+static const u8 xboxone_rumblebegin_init[] = {
+ 0x09, 0x00, 0x00, 0x09, 0x00, 0x0F, 0x00, 0x00,
+ 0x1D, 0x1D, 0xFF, 0x00, 0x00
+};
+
+/*
+ * A rumble packet with zero FF intensity will immediately
+ * terminate the rumbling required to init PowerA pads.
+ * This should happen fast enough that the motors don't
+ * spin up to enough speed to actually vibrate the gamepad.
+ */
+static const u8 xboxone_rumbleend_init[] = {
0x09, 0x00, 0x00, 0x09, 0x00, 0x0F, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00
};
@@ -407,9 +418,12 @@ static const struct xboxone_init_packet
XBOXONE_INIT_PKT(0x0e6f, 0x0165, xboxone_hori_init),
XBOXONE_INIT_PKT(0x0f0d, 0x0067, xboxone_hori_init),
XBOXONE_INIT_PKT(0x, 0x, xboxone_fw2015_init),
- XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_zerorumble_init),
- XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_zerorumble_init),
- XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_zerorumble_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_rumblebegin_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_rumblebegin_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumblebegin_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_rumbleend_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_rumbleend_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumbleend_init),
};
struct xpad_output_packet {
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote: > So you worry about max_active==1 ? Or you worry about pool->lock or > about the thread setup? I'm still not sure. So the thing about pool->lock is that its a leaf lock, we take nothing inside it. Futhermore its a spinlock and therefore blocking things like completions or page-lock cannot form a deadlock with it. It is also fully isolated inside workqueue.c and easy to audit. This is why I really can't be arsed about it. And the whole setup stuff isn't properly preserved between works in any case, only the first few works would ever see that history, so why bother. We _could_ save/restore the setup history, by doing a complete copy of it and restoring that, but that's not what crossrelease did, and I really don't see the point.
[PATCH 1/2] PCI: iproc: export iproc_pcie_shutdown symbol
The shutdown bugfix introduce a build regression for allmodconfig
kernels as the new function is not exported:
ERROR: "iproc_pcie_shutdown" [drivers/pci/host/pcie-iproc-platform.ko]
undefined!
This adds the missing export.
Fixes: 2a9912565c05 ("PCI: iproc: Add 500ms delay during device shutdown")
Signed-off-by: Arnd Bergmann
---
drivers/pci/host/pcie-iproc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 8bd5e544b1c1..d7f4c29aed96 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -704,6 +704,7 @@ int iproc_pcie_shutdown(struct iproc_pcie *pcie)
return 0;
}
+EXPORT_SYMBOL_GPL(iproc_pcie_shutdown);
static int iproc_pcie_check_link(struct iproc_pcie *pcie)
{
--
2.9.0
[PATCH 4.9 10/18] alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.
This fixes compiler errors in perf such as:
tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long
unsigned int', but argument 6 has type '__u64 {aka long unsigned int}'
[-Werror=format=]
snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
^
Signed-off-by: Ben Hutchings
Tested-by: Michael Cree
Signed-off-by: Matt Turner
Signed-off-by: Greg Kroah-Hartman
---
arch/alpha/include/asm/types.h |2 +-
arch/alpha/include/uapi/asm/types.h | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/arch/alpha/include/asm/types.h
+++ b/arch/alpha/include/asm/types.h
@@ -1,6 +1,6 @@
#ifndef _ALPHA_TYPES_H
#define _ALPHA_TYPES_H
-#include
+#include
#endif /* _ALPHA_TYPES_H */
--- a/arch/alpha/include/uapi/asm/types.h
+++ b/arch/alpha/include/uapi/asm/types.h
@@ -9,8 +9,18 @@
* need to be careful to avoid a name clashes.
*/
-#ifndef __KERNEL__
+/*
+ * This is here because we used to use l64 for alpha
+ * and we don't want to impact user mode with our change to ll64
+ * in the kernel.
+ *
+ * However, some user programs are fine with this. They can
+ * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
+ */
+#if !defined(__SANE_USERSPACE_TYPES__) && !defined(__KERNEL__)
#include
+#else
+#include
#endif
#endif /* _UAPI_ALPHA_TYPES_H */
[PATCH 4.12 10/27] mm, uprobes: fix multiple free of ->uprobes_state.xol_area
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 355627f518978b5167256d27492fe0b343aaf2f2 upstream.
Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().
However, it was overlooked that this introduced an new error path before
the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
being copied from the old mm_struct by the memcpy in dup_mm(). For a
task that has previously hit a uprobe tracepoint, this resulted in the
'struct xol_area' being freed multiple times if the task was killed at
just the right time while forking.
Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
than in uprobe_dup_mmap().
With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of
->exe_file causing use-after-free"), provided that a uprobe tracepoint
has been set on the fork_thread() function. For example:
$ gcc reproducer.c -o reproducer -lpthread
$ nm reproducer | grep fork_thread
00400719 t fork_thread
$ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
$ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
$ ./reproducer
Here is the use-after-free reported by KASAN:
BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
Read of size 8 at addr 8800320a8b88 by task reproducer/198
CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5
#255
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-20170228_101828-anatol 04/01/2014
Call Trace:
dump_stack+0xdb/0x185
print_address_description+0x7e/0x290
kasan_report+0x23b/0x350
__asan_report_load8_noabort+0x19/0x20
uprobe_clear_state+0x1c4/0x200
mmput+0xd6/0x360
do_exit+0x740/0x1670
do_group_exit+0x13f/0x380
get_signal+0x597/0x17d0
do_signal+0x99/0x1df0
exit_to_usermode_loop+0x166/0x1e0
syscall_return_slowpath+0x258/0x2c0
entry_SYSCALL_64_fastpath+0xbc/0xbe
...
Allocated by task 199:
save_stack_trace+0x1b/0x20
kasan_kmalloc+0xfc/0x180
kmem_cache_alloc_trace+0xf3/0x330
__create_xol_area+0x10f/0x780
uprobe_notify_resume+0x1674/0x2210
exit_to_usermode_loop+0x150/0x1e0
prepare_exit_to_usermode+0x14b/0x180
retint_user+0x8/0x20
Freed by task 199:
save_stack_trace+0x1b/0x20
kasan_slab_free+0xa8/0x1a0
kfree+0xba/0x210
uprobe_clear_state+0x151/0x200
mmput+0xd6/0x360
copy_process.part.8+0x605f/0x65d0
_do_fork+0x1a5/0xbd0
SyS_clone+0x19/0x20
do_syscall_64+0x22f/0x660
return_from_SYSCALL_64+0x0/0x7a
Note: without KASAN, you may instead see a "Bad page state" message, or
simply a general protection fault.
Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebigge...@gmail.com
Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write
killable")
Signed-off-by: Eric Biggers
Reported-by: Oleg Nesterov
Acked-by: Oleg Nesterov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Dmitry Vyukov
Cc: Ingo Molnar
Cc: Konstantin Khlebnikov
Cc: Mark Rutland
Cc: Michal Hocko
Cc: Peter Zijlstra
Cc: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
kernel/events/uprobes.c |2 --
kernel/fork.c |8
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1262,8 +1262,6 @@ void uprobe_end_dup_mmap(void)
void uprobe_dup_mmap(struct mm_struct *oldmm, struct mm_struct *newmm)
{
- newmm->uprobes_state.xol_area = NULL;
-
if (test_bit(MMF_HAS_UPROBES, &oldmm->flags)) {
set_bit(MMF_HAS_UPROBES, &newmm->flags);
/* unconditionally, dup_mmap() skips VM_DONTCOPY vmas */
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -781,6 +781,13 @@ static void mm_init_owner(struct mm_stru
#endif
}
+static void mm_init_uprobes_state(struct mm_struct *mm)
+{
+#ifdef CONFIG_UPROBES
+ mm->uprobes_state.xol_area = NULL;
+#endif
+}
+
static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
struct user_namespace *user_ns)
{
@@ -808,6 +815,7 @@ static struct mm_struct *mm_init(struct
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
mm->pmd_huge_pte = NULL;
#endif
+ mm_init_uprobes_state(mm);
if (current->mm) {
mm->flags = current->mm->flags & MMF_INIT_MASK;
[PATCH 4.12 12/27] ceph: fix readpage from fscache
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Yan, Zheng
commit dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream.
ceph_readpage() unlocks page prematurely prematurely in the case
that page is reading from fscache. Caller of readpage expects that
page is uptodate when it get unlocked. So page shoule get locked
by completion callback of fscache_read_or_alloc_pages()
Signed-off-by: "Yan, Zheng"
Reviewed-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman
---
fs/ceph/addr.c | 24 +++-
fs/ceph/cache.c | 12 +++-
2 files changed, 18 insertions(+), 18 deletions(-)
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -189,7 +189,7 @@ static int ceph_releasepage(struct page
/*
* read a single page, without unlocking it.
*/
-static int readpage_nounlock(struct file *filp, struct page *page)
+static int ceph_do_readpage(struct file *filp, struct page *page)
{
struct inode *inode = file_inode(filp);
struct ceph_inode_info *ci = ceph_inode(inode);
@@ -219,7 +219,7 @@ static int readpage_nounlock(struct file
err = ceph_readpage_from_fscache(inode, page);
if (err == 0)
- goto out;
+ return -EINPROGRESS;
dout("readpage inode %p file %p page %p index %lu\n",
inode, filp, page, page->index);
@@ -249,8 +249,11 @@ out:
static int ceph_readpage(struct file *filp, struct page *page)
{
- int r = readpage_nounlock(filp, page);
- unlock_page(page);
+ int r = ceph_do_readpage(filp, page);
+ if (r != -EINPROGRESS)
+ unlock_page(page);
+ else
+ r = 0;
return r;
}
@@ -1240,7 +1243,7 @@ retry_locked:
goto retry_locked;
r = writepage_nounlock(page, NULL);
if (r < 0)
- goto fail_nosnap;
+ goto fail_unlock;
goto retry_locked;
}
@@ -1268,11 +1271,14 @@ retry_locked:
}
/* we need to read it. */
- r = readpage_nounlock(file, page);
- if (r < 0)
- goto fail_nosnap;
+ r = ceph_do_readpage(file, page);
+ if (r < 0) {
+ if (r == -EINPROGRESS)
+ return -EAGAIN;
+ goto fail_unlock;
+ }
goto retry_locked;
-fail_nosnap:
+fail_unlock:
unlock_page(page);
return r;
}
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -240,13 +240,7 @@ void ceph_fscache_file_set_cookie(struct
}
}
-static void ceph_vfs_readpage_complete(struct page *page, void *data, int
error)
-{
- if (!error)
- SetPageUptodate(page);
-}
-
-static void ceph_vfs_readpage_complete_unlock(struct page *page, void *data,
int error)
+static void ceph_readpage_from_fscache_complete(struct page *page, void *data,
int error)
{
if (!error)
SetPageUptodate(page);
@@ -274,7 +268,7 @@ int ceph_readpage_from_fscache(struct in
return -ENOBUFS;
ret = fscache_read_or_alloc_page(ci->fscache, page,
-ceph_vfs_readpage_complete, NULL,
+ceph_readpage_from_fscache_complete,
NULL,
GFP_KERNEL);
switch (ret) {
@@ -303,7 +297,7 @@ int ceph_readpages_from_fscache(struct i
return -ENOBUFS;
ret = fscache_read_or_alloc_pages(ci->fscache, mapping, pages, nr_pages,
- ceph_vfs_readpage_complete_unlock,
+ ceph_readpage_from_fscache_complete,
NULL, mapping_gfp_mask(mapping));
switch (ret) {
[PATCH 4.12 01/27] arm64: mm: abort uaccess retries upon fatal signal
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Rutland
commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.
When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Cc: Catalin Marinas
Cc: Laura Abbott
Reviewed-by: Steve Capper
Tested-by: Steve Capper
Reviewed-by: James Morse
Tested-by: James Morse
Signed-off-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/mm/fault.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -397,8 +397,11 @@ retry:
* signal first. We do not need to release the mmap_sem because it
* would already be released in __lock_page_or_retry in mm/filemap.c.
*/
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/*
* Major/minor page fault accounting is only done on the initial
[PATCH 4.9 17/18] kvm: arm/arm64: Force reading uncached stage2 PGD
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Suzuki K Poulose
commit 2952a6070e07ebdd5896f1f5b861acad677caded upstream.
Make sure we don't use a cached value of the KVM stage2 PGD while
resetting the PGD.
Cc: Marc Zyngier
Signed-off-by: Suzuki K Poulose
Reviewed-by: Christoffer Dall
Signed-off-by: Christoffer Dall
Signed-off-by: Suzuki K Poulose
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/kvm/mmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -837,7 +837,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm
spin_lock(&kvm->mmu_lock);
if (kvm->arch.pgd) {
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
- pgd = kvm->arch.pgd;
+ pgd = READ_ONCE(kvm->arch.pgd);
kvm->arch.pgd = NULL;
}
spin_unlock(&kvm->mmu_lock);
Re: 答复: [PATCH v4] mfd: Add support for RTS5250S power saving
On Tue, 05 Sep 2017, 冯锐 wrote:
> Dear Jones,
>
> > +static void rts5250_set_l1off_cfg_sub_d0(struct rtsx_pcr *pcr, int
> > +active) {
> > + struct rtsx_cr_option *option = &(pcr->option);
> > +
> > + u32 interrupt = rtsx_pci_readl(pcr, RTSX_BIPR);
> > + int card_exist = (interrupt & SD_EXIST) | (interrupt & MS_EXIST);
> > + int aspm_L1_1, aspm_L1_2;
> > + u8 val = 0;
>
> No need to pre-allocate.
All of my responses should now be quotes, but they are not.
This makes replying to your messages difficult.
Please fix your editor.
> If val is not pre-allocated, what will the val be if it is not assigned
> before using?
You do not use it before assigning it.
> > + aspm_L1_1 = rtsx_check_dev_flag(pcr, ASPM_L1_1_EN);
> > + aspm_L1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN);
> > +
> > + if (active) {
> > + /* run, latency: 60us */
> > + if (aspm_L1_1)
> > + val = option->ltr_l1off_snooze_sspwrgate;
> > + } else {
> > + /* l1off, latency: 300us */
> > + if (aspm_L1_2)
> > + val = option->ltr_l1off_sspwrgate;
> > + }
> > +
> > + if (aspm_L1_1 || aspm_L1_2) {
> > + if (rtsx_check_dev_flag(pcr,
> > + LTR_L1SS_PWR_GATE_CHECK_CARD_EN)) {
> > + if (card_exist)
> > + val &= ~L1OFF_MBIAS2_EN_5250;
> > + else
> > + val |= L1OFF_MBIAS2_EN_5250;
> > + }
> > + }
> > + rtsx_set_l1off_sub(pcr, val);
> > +}
> > +
> > static const struct pcr_ops rts524a_pcr_ops = {
> > .write_phy = rts524a_write_phy,
> > .read_phy = rts524a_read_phy,
> > @@ -473,11 +617,16 @@ static int rts524a_extra_init_hw(struct rtsx_pcr *pcr)
> > .card_power_off = rtsx_base_card_power_off,
> > .switch_output_voltage = rtsx_base_switch_output_voltage,
> > .force_power_down = rtsx_base_force_power_down,
> > + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> > + .set_aspm = rts5249_set_aspm,
> > };
> >
> > void rts524a_init_params(struct rtsx_pcr *pcr) {
> > rts5249_init_params(pcr);
> > + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> > + pcr->option.ltr_l1off_snooze_sspwrgate =
> > + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
> >
> > pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> > pcr->ops = &rts524a_pcr_ops;
> > @@ -576,11 +725,16 @@ static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
> > .card_power_off = rtsx_base_card_power_off,
> > .switch_output_voltage = rts525a_switch_output_voltage,
> > .force_power_down = rtsx_base_force_power_down,
> > + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> > + .set_aspm = rts5249_set_aspm,
> > };
> >
> > void rts525a_init_params(struct rtsx_pcr *pcr) {
> > rts5249_init_params(pcr);
> > + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> > + pcr->option.ltr_l1off_snooze_sspwrgate =
> > + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
> >
> > pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> > pcr->ops = &rts525a_pcr_ops;
> > diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index
> > a0ac89d..50a6e67 100644
> > --- a/drivers/mfd/rtsx_pcr.c
> > +++ b/drivers/mfd/rtsx_pcr.c
> > @@ -79,6 +79,131 @@ static inline void rtsx_pci_disable_aspm(struct
> > rtsx_pcr *pcr)
> > 0xFC, 0);
> > }
> >
> > +int rtsx_comm_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> > + rtsx_pci_write_register(pcr, MSGTXDATA0, 0xFF, (u8) (latency &
> > +0xFF));
>
> What is (the first) 0xFF?
>
> 0xFF is just 8 bit mask.
I mean the first one.
> > + rtsx_pci_write_register(pcr, MSGTXDATA1,
> > + 0xFF, (u8)((latency >> 8) & 0xFF));
> > + rtsx_pci_write_register(pcr, MSGTXDATA2,
> > + 0xFF, (u8)((latency >> 16) & 0xFF));
> > + rtsx_pci_write_register(pcr, MSGTXDATA3,
> > + 0xFF, (u8)((latency >> 24) & 0xFF));
> > + rtsx_pci_write_register(pcr, LTR_CTL, LTR_TX_EN_MASK |
> > + LTR_LATENCY_MODE_MASK, LTR_TX_EN_1 | LTR_LATENCY_MODE_SW);
> > +
> > + return 0;
> > +}
> > +
> > +int rtsx_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> > + if (pcr->ops->set_ltr_latency)
> > + return pcr->ops->set_ltr_latency(pcr, latency);
> > + else
> > + return rtsx_comm_set_ltr_latency(pcr, latency); }
> > +
> > +static void rtsx_comm_set_aspm(struct rtsx_pcr *pcr, bool enable) {
> > + struct rtsx_cr_option *option = &pcr->option;
> > +
> > + if (pcr->aspm_enabled == enable)
> > + return;
> > +
> > + if (option->dev_aspm_mode == DEV_ASPM_DYNAMIC) {
> > + if (enable)
> > + rtsx_pci_enable_aspm(pcr);
> > + else
> > + rtsx_pci_disable_aspm(pcr);
> > + } else if (option->dev_aspm_mode == DEV_ASPM_BACKDOOR) {
> > + u8 mask = FORCE_ASPM_VAL_MASK;
[PATCH 2/2] PCI: iproc: fix Stingray CRS defect handling
The condition that was used to detect the PCI_EXP_RTCAP
flag access is wrong, as pointed out by gcc-8:
drivers/pci/host/pcie-iproc.c: In function 'iproc_pcie_config_read':
drivers/pci/host/pcie-iproc.c:531:22: error: bitwise comparison always
evaluates to false [-Werror=tautological-compare]
if ((where & ~0x3) == PCI_EXP_CAP + PCI_EXP_RTCAP)
This adds the same bit mask to the other end as well, so the
condition is evaluated correctly for any access.
Fixes: ac8d3e852f75 ("PCI: iproc: Work around Stingray CRS defects")
Signed-off-by: Arnd Bergmann
---
drivers/pci/host/pcie-iproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index d7f4c29aed96..f2df9c2266b9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -528,7 +528,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
return ret;
/* Don't advertise CRS SV support */
- if ((where & ~0x3) == PCI_EXP_CAP + PCI_EXP_RTCAP)
+ if ((where & ~0x3) == ((PCI_EXP_CAP + PCI_EXP_RTCAP) & ~0x03))
*val &= ~(PCI_EXP_RTCAP_CRSVIS << 16);
return PCIBIOS_SUCCESSFUL;
}
--
2.9.0
[PATCH 4.9 15/18] xfrm: policy: check policy direction value
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vladis Dronov
commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint
address(es)")
Reported-by: "bo Zhang"
Signed-off-by: Vladis Dronov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_policy.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3308,9 +3308,15 @@ int xfrm_migrate(const struct xfrm_selec
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
+ /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
+ if (dir >= XFRM_POLICY_MAX) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
[PATCH 4.9 06/18] mm, madvise: ensure poisoned pages are removed from per-cpu lists
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Mel Gorman
commit c461ad6a63b37ba74632e90c063d14823c884247 upstream.
Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed
and bisected it to the commit 479f854a207c ("mm, page_alloc: defer
debugging checks of pages allocated from the PCP").
The problem is that a page that was poisoned with madvise() is reused.
The commit removed a check that would trigger if DEBUG_VM was enabled
but re-enabling the check only fixes the problem as a side-effect by
printing a bad_page warning and recovering.
The root of the problem is that an madvise() can leave a poisoned page
on the per-cpu list. This patch drains all per-cpu lists after pages
are poisoned so that they will not be reused. Wendy reports that the
test case in question passes with this patch applied. While this could
be done in a targeted fashion, it is over-complicated for such a rare
operation.
Link:
http://lkml.kernel.org/r/20170828133414.7qro57jbepdcy...@techsingularity.net
Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated
from the PCP")
Signed-off-by: Mel Gorman
Reported-by: Wang, Wendy
Tested-by: Wang, Wendy
Acked-by: David Rientjes
Acked-by: Vlastimil Babka
Cc: "Hansen, Dave"
Cc: "Luck, Tony"
Cc: Naoya Horiguchi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/madvise.c |7 +++
1 file changed, 7 insertions(+)
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -533,6 +533,8 @@ static long madvise_remove(struct vm_are
static int madvise_hwpoison(int bhv, unsigned long start, unsigned long end)
{
struct page *p;
+ struct zone *zone;
+
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
for (; start < end; start += PAGE_SIZE <<
@@ -561,6 +563,11 @@ static int madvise_hwpoison(int bhv, uns
if (ret)
return ret;
}
+
+ /* Ensure that all poisoned pages are removed from per-cpu lists */
+ for_each_populated_zone(zone)
+ drain_all_pages(zone);
+
return 0;
}
#endif
Re: [PATCH 6/7] ASoC: arizona: Add support for setting the output volume limits
On Mon, 04 Sep 2017, Charles Keepax wrote: > The output volume limits allow signals to be limited to specific levels > appropriate for the hardware attached. As this is a property of the > hardware itself these will be configured through device tree. > > Signed-off-by: Charles Keepax > --- > include/linux/mfd/arizona/pdata.h | 3 +++ Acked-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature
James, On 2017/9/1 2:04, James Morse wrote: > Hi Dongjiu Geng, > > On 28/08/17 11:38, Dongjiu Geng wrote: >> In ARMV8.2 RAS extension, a virtual SError exception syndrome >> register(VSESR_EL2) is added. This value may be specified from >> userspace. > > I agree that the CPU support for injecting SErrors with a specified ESR should > be exposed to KVM's user space... Ok, thanks. > > >> Userspace will want to check if the CPU has the RAS >> extension. > > ... but user-space wants to know if it can inject SErrors with a specified > ESR. > > What if we gain another way of doing this that isn't via the RAS-extensions, > now > user-space has to check for two capabilities. > > >> If it has, it wil specify the virtual SError syndrome >> value, otherwise it will not be set. This patch adds support for >> querying the availability of this extension. > > I'm against telling user-space what features the CPU has unless it can use > them > directly. In this case we are talking about a KVM API, so we should describe > the > API not the CPU. shenglong (zhaoshengl...@huawei.com) who is Qemu maintainer suggested checking the CPU RAS-extensions to decide whether generate the APEI table and record CPER for the guest OS in the user space. he means if the host does not support RAS, user space may also not support RAS. > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 3256b9228e75..b7313ee028e9 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> case KVM_CAP_ARM_PMU_V3: >> r = kvm_arm_support_pmu_v3(); >> break; >> +case KVM_CAP_ARM_RAS_EXTENSION: > > This should be called something more like 'KVM_CAP_ARM_INJECT_SERROR_ESR' I understand your suggestion. > > >> +r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); >> +break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> r = 1; > > > We can inject SError on systems without the RAS extensions using just the > HCR_EL2.VSE bit. We may want to make the 'ESR' part of the API optional, or > expose '1' for the without-ESR version and '2 for with-ESR, (however we choose > to implement that). > > The risk is if we want to add a without-ESR version later, and the name we > make > ABI now turned out to be a mistake. Marc or Christoffer probably have the best > view of this. (no-one has needed it so far...) > > > Thanks, > > James > > > . >
Re: [PATCH 2/3] lockdep: Introduce lock_acquire_might()
On Tue, Sep 05, 2017 at 11:29:13AM +0900, Byungchul Park wrote: > From the point of view of crossrelease, we can never be aware of the > release context in advance, until we get to the lock_release(). > However, this way we cannot report deadlocks occured at the time. > > Sometimes, we want to report that kind of problems, taking a risk > generating false dependencies e.g. lock_acquire()s in workqueue code, > which inevitably generate false ones with all acquisitions in works. > > It would be better to provide another primitive, lock_acquire_might() > for that purpose so that lockdep internal can be aware of what users > expect and get chances to enhance to avoid false ones. > > The primitive should: > >1. work as if it's trylock, since links between lock_acquire_might() > and later ones are only meaningful. Remind this should be used to > do what crossrelease commit does, in advance. > >2. make acquisitions by lock_acquire_might() ignored on the commit. > Shees, talk about ugly... Also might-lock has a different meaning.
[PATCH 4.9 12/18] CIFS: remove endian related sparse warning
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
Recent patch had an endian warning ie
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Signed-off-by: Steve French
CC: Ronnie Sahlberg
Acked-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -194,7 +194,7 @@ check_name(struct dentry *direntry, stru
int i;
if (unlikely(direntry->d_name.len >
-tcon->fsAttrInfo.MaxPathNameComponentLength))
+le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
return -ENAMETOOLONG;
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)) {
Re: [PATCH 2/2] mm, memory_hotplug: remove timeout from __offline_memory
On Tue 05-09-17 11:16:57, Anshuman Khandual wrote: > On 09/04/2017 02:45 PM, Michal Hocko wrote: > > On Mon 04-09-17 17:05:15, Xishi Qiu wrote: > >> On 2017/9/4 17:01, Michal Hocko wrote: > >> > >>> On Mon 04-09-17 16:58:30, Xishi Qiu wrote: > On 2017/9/4 16:21, Michal Hocko wrote: > > > From: Michal Hocko > > > > We have a hardcoded 120s timeout after which the memory offline fails > > basically since the hot remove has been introduced. This is essentially > > a policy implemented in the kernel. Moreover there is no way to adjust > > the timeout and so we are sometimes facing memory offline failures if > > the system is under a heavy memory pressure or very intensive CPU > > workload on large machines. > > > > It is not very clear what purpose the timeout actually serves. The > > offline operation is interruptible by a signal so if userspace wants > Hi Michal, > > If the user know what he should do if migration for a long time, > it is OK, but I don't think all the users know this operation > (e.g. ctrl + c) and the affect. > >>> How is this operation any different from other potentially long > >>> interruptible syscalls? > >>> > >> Hi Michal, > >> > >> I means the user should stop it by himself if migration always retry in > >> endless. > > If the memory is migrateable then the migration should finish > > eventually. It can take some time but it shouldn't be an endless loop. > > But what if some how the temporary condition (page removed from the PCP > LRU list and has not been freed yet to the buddy) happens again and again. How would that happen? We have all pages in the range MIGRATE_ISOLATE so no pages will get reallocated and we know that there are no unmigratable pages in the range. So we only should have temporary failures for migration. If that is not the case then we have a bug somewhere. > I understand we have schedule() and yield() to make sure that the context > does not hold the CPU for ever but it can take theoretically very long > time if not endless to finish. In that case sending signal to the user I guess you meant to say signal from the user space... > space process who initiated the offline request is the only way to stop > this retry loop. I think this is still a better approach than the 120 > second timeout which was kind of arbitrary. Yeah the context is interruptible so if the operation takes unbearably too long then a watchdog can be setup trivially and to the user defined value. There is a good reason we do not add hardocded timeouts to the kernel. -- Michal Hocko SUSE Labs
Re: [PATCH 4/7] mfd: arizona: Remove audio related device tree code
On Mon, 04 Sep 2017, Charles Keepax wrote: > This code has now been moved to the audio subsystem so is no longer > required in the MFD code. > > Signed-off-by: Charles Keepax > --- > drivers/mfd/arizona-core.c | 132 > + > 1 file changed, 1 insertion(+), 131 deletions(-) I will require pull-request for this patch, but: Acked-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 4.9 13/18] wl1251: add a missing spin_lock_init()
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Cong Wang commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream. wl1251: add a missing spin_lock_init() This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #40 [ 5668.772796] Hardware name: Nokia RX-51 board [ 5668.773071] Workqueue: phy1 wl1251_irq_work [ 5668.773345] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5668.773803] [] (show_stack) from [] (do_raw_spin_lock+0x6c/0xa0) [ 5668.774230] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x10/0x18) [ 5668.774658] [] (_raw_spin_lock_irqsave) from [] (wl1251_op_tx+0x38/0x5c) [ 5668.775115] [] (wl1251_op_tx) from [] (ieee80211_tx_frags+0x188/0x1c0) [ 5668.775543] [] (ieee80211_tx_frags) from [] (__ieee80211_tx+0x6c/0x130) [ 5668.775970] [] (__ieee80211_tx) from [] (ieee80211_tx+0xdc/0x104) [ 5668.776367] [] (ieee80211_tx) from [] (__ieee80211_subif_start_xmit+0x454/0x8c8) [ 5668.776824] [] (__ieee80211_subif_start_xmit) from [] (ieee80211_subif_start_xmit+0x30/0x2fc) [ 5668.777343] [] (ieee80211_subif_start_xmit) from [] (dev_hard_start_xmit+0x80/0x118) ... by adding the missing spin_lock_init(). Reported-by: Pavel Machek Cc: Kalle Valo Signed-off-by: Cong Wang Acked-by: Pavel Machek Signed-off-by: Kalle Valo Signed-off-by: Pavel Machek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ti/wl1251/main.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1571,6 +1571,7 @@ struct ieee80211_hw *wl1251_alloc_hw(voi wl->state = WL1251_STATE_OFF; mutex_init(&wl->mutex); + spin_lock_init(&wl->wl_lock); wl->tx_mgmt_frm_rate = DEFAULT_HW_GEN_TX_RATE; wl->tx_mgmt_frm_mod = DEFAULT_HW_GEN_MODULATION_TYPE;
Re: [PATCH 5/7] mfd: arizona: Remove audio bindings from MFD binding document
On Mon, 04 Sep 2017, Charles Keepax wrote: > Now the audio bindings have their own binding document update the main > MFD document to point to that file and remove the audio binding > documentation. > > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 40 > +-- > 1 file changed, 1 insertion(+), 39 deletions(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver
Oleksandr Andrushchenko wrote: >>> We understand that emulated interrupt on the frontend side is completely not >>> acceptable Allow me to expand on that: Proper synchronization requires that the exact position is communicated, not estimated. Just because the nominal rate of the stream is known does not imply that you know the actual rate. Forget for the moment that there even is a nominal rate; assume that it works like, e.g., a storage controller, and that you can know that a DMA buffer was consumed by the device only after it has told you. It's possible and likely that there is a latency when reporting the stream position, but that is still better than guessing what the DMA is doing. (You would never just try to guess when writing data to disk, would you?) >>> and definitely we need to provide some feedback mechanism from >>> Dom0 to DomU. >>> >>> In our case it is technically impossible to provide precise period interrupt >>> (mostly because our backend is a user space application). As far as I can see, all audio APIs (ALSA, PulseAudio, etc.) have poll() or callbacks or similar mechanisms to inform you when new data can be written, and always allow to query the current position. > [...] > ok, so the main concern here is that we cannot properly synchronize Dom0-DomU. > If we put this apart for a second are there any other concerns on having ALSA > frontend driver? If not, can we have the driver with timer implementation > upstreamed > as experimental until we have some acceptable synchronization solution? > This will allow broader audience to try and feel the solution and probably > contribute? I doubt that the driver architecture will stay completely the same, so I do not think that this experimental driver would demonstrate how the solution would feel. As the first step, I would suggest creating a driver with proper synchronization, even if it has high latency. Reducing the latency would then be 'just' an optimization. Regards, Clemens
[PATCH 4.9 11/18] CIFS: Fix maximum SMB2 header size
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Pavel Shilovsky commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/cifs/smb2pdu.h +++ b/fs/cifs/smb2pdu.h @@ -84,8 +84,8 @@ #define NUMBER_OF_SMB2_COMMANDS0x0013 -/* BB FIXME - analyze following length BB */ -#define MAX_SMB2_HDR_SIZE 0x78 /* 4 len + 64 hdr + (2*24 wct) + 2 bct + 2 pad */ +/* 4 len + 52 transform hdr + 64 hdr + 56 create rsp */ +#define MAX_SMB2_HDR_SIZE 0x00b0 #define SMB2_PROTO_NUMBER cpu_to_le32(0x424d53fe) #define SMB2_TRANSFORM_PROTO_NUM cpu_to_le32(0x424d53fd)
[PATCH 4.9 09/18] cpuset: Fix incorrect memory_pressure control file mapping
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Waiman Long
commit 1c08c22c874ac88799cab1f78c40f46110274915 upstream.
The memory_pressure control file was incorrectly set up without
a private value (0, by default). As a result, this control
file was treated like memory_migrate on read. By adding back the
FILE_MEMORY_PRESSURE private value, the correct memory pressure value
will be returned.
Signed-off-by: Waiman Long
Signed-off-by: Tejun Heo
Fixes: 7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE")
Signed-off-by: Greg Kroah-Hartman
---
kernel/cpuset.c |1 +
1 file changed, 1 insertion(+)
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1905,6 +1905,7 @@ static struct cftype files[] = {
{
.name = "memory_pressure",
.read_u64 = cpuset_read_u64,
+ .private = FILE_MEMORY_PRESSURE,
},
{
[PATCH 4.9 05/18] mm, uprobes: fix multiple free of ->uprobes_state.xol_area
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 355627f518978b5167256d27492fe0b343aaf2f2 upstream.
Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().
However, it was overlooked that this introduced an new error path before
the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
being copied from the old mm_struct by the memcpy in dup_mm(). For a
task that has previously hit a uprobe tracepoint, this resulted in the
'struct xol_area' being freed multiple times if the task was killed at
just the right time while forking.
Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
than in uprobe_dup_mmap().
With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of
->exe_file causing use-after-free"), provided that a uprobe tracepoint
has been set on the fork_thread() function. For example:
$ gcc reproducer.c -o reproducer -lpthread
$ nm reproducer | grep fork_thread
00400719 t fork_thread
$ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
$ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
$ ./reproducer
Here is the use-after-free reported by KASAN:
BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
Read of size 8 at addr 8800320a8b88 by task reproducer/198
CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5
#255
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-20170228_101828-anatol 04/01/2014
Call Trace:
dump_stack+0xdb/0x185
print_address_description+0x7e/0x290
kasan_report+0x23b/0x350
__asan_report_load8_noabort+0x19/0x20
uprobe_clear_state+0x1c4/0x200
mmput+0xd6/0x360
do_exit+0x740/0x1670
do_group_exit+0x13f/0x380
get_signal+0x597/0x17d0
do_signal+0x99/0x1df0
exit_to_usermode_loop+0x166/0x1e0
syscall_return_slowpath+0x258/0x2c0
entry_SYSCALL_64_fastpath+0xbc/0xbe
...
Allocated by task 199:
save_stack_trace+0x1b/0x20
kasan_kmalloc+0xfc/0x180
kmem_cache_alloc_trace+0xf3/0x330
__create_xol_area+0x10f/0x780
uprobe_notify_resume+0x1674/0x2210
exit_to_usermode_loop+0x150/0x1e0
prepare_exit_to_usermode+0x14b/0x180
retint_user+0x8/0x20
Freed by task 199:
save_stack_trace+0x1b/0x20
kasan_slab_free+0xa8/0x1a0
kfree+0xba/0x210
uprobe_clear_state+0x151/0x200
mmput+0xd6/0x360
copy_process.part.8+0x605f/0x65d0
_do_fork+0x1a5/0xbd0
SyS_clone+0x19/0x20
do_syscall_64+0x22f/0x660
return_from_SYSCALL_64+0x0/0x7a
Note: without KASAN, you may instead see a "Bad page state" message, or
simply a general protection fault.
Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebigge...@gmail.com
Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write
killable")
Signed-off-by: Eric Biggers
Reported-by: Oleg Nesterov
Acked-by: Oleg Nesterov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Dmitry Vyukov
Cc: Ingo Molnar
Cc: Konstantin Khlebnikov
Cc: Mark Rutland
Cc: Michal Hocko
Cc: Peter Zijlstra
Cc: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
kernel/events/uprobes.c |2 --
kernel/fork.c |8
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1254,8 +1254,6 @@ void uprobe_end_dup_mmap(void)
void uprobe_dup_mmap(struct mm_struct *oldmm, struct mm_struct *newmm)
{
- newmm->uprobes_state.xol_area = NULL;
-
if (test_bit(MMF_HAS_UPROBES, &oldmm->flags)) {
set_bit(MMF_HAS_UPROBES, &newmm->flags);
/* unconditionally, dup_mmap() skips VM_DONTCOPY vmas */
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -745,6 +745,13 @@ static void mm_init_owner(struct mm_stru
#endif
}
+static void mm_init_uprobes_state(struct mm_struct *mm)
+{
+#ifdef CONFIG_UPROBES
+ mm->uprobes_state.xol_area = NULL;
+#endif
+}
+
static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
struct user_namespace *user_ns)
{
@@ -772,6 +779,7 @@ static struct mm_struct *mm_init(struct
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
mm->pmd_huge_pte = NULL;
#endif
+ mm_init_uprobes_state(mm);
if (current->mm) {
mm->flags = current->mm->flags & MMF_INIT_MASK;
Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC
On Mon, 04 Sep 2017, Takashi Iwai wrote: > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with > ACPI INT33F5 that is found on some Intel Cherry Trail devices. > The driver is based on the original work by Intel, found at: > https://github.com/01org/ProductionKernelQuilts > > This is a minimal version for adding the basic resources. Currently, > only ACPI PMIC opregion and the external power-button are used. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891 > Reviewed-by: Mika Westerberg > Reviewed-by: Andy Shevchenko > Signed-off-by: Takashi Iwai > --- > v4->v5: > * Minor coding-style fixes suggested by Lee > * Put GPL text > v3->v4: > * no change for this patch > v2->v3: > * Rename dc_ti with chtdc_ti in all places > * Driver/kconfig renames accordingly > * Added acks by Andy and Mika > v1->v2: > * Minor cleanups as suggested by Andy > > drivers/mfd/Kconfig | 13 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 > ++ > 3 files changed, 198 insertions(+) > create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 4.9 08/18] cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit b339752d054fb32863418452dff350a1086885b1 upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by: Tejun Heo Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/asm-generic/topology.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/include/asm-generic/topology.h +++ b/include/asm-generic/topology.h @@ -48,7 +48,11 @@ #define parent_node(node) ((void)(node),0) #endif #ifndef cpumask_of_node -#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #ifdef CONFIG_NEED_MULTIPLE_NODES +#define cpumask_of_node(node) ((node) == 0 ? cpu_online_mask : cpu_none_mask) + #else +#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #endif #endif #ifndef pcibus_to_node #define pcibus_to_node(bus)((void)(bus), -1)
Re: [PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt workqueue flush
On Tue, Sep 05, 2017 at 11:29:14AM +0900, Byungchul Park wrote: > Also, lock_map_acquire() in process_one_work() is too strong for > that purpose. lock_map_acquire_might() is enough. Replaced it. NAK!! traditional annotations are superior to cross-release. They are not timing dependent.
[PATCH 4.9 07/18] ceph: fix readpage from fscache
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Yan, Zheng
commit dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream.
ceph_readpage() unlocks page prematurely prematurely in the case
that page is reading from fscache. Caller of readpage expects that
page is uptodate when it get unlocked. So page shoule get locked
by completion callback of fscache_read_or_alloc_pages()
Signed-off-by: "Yan, Zheng"
Reviewed-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman
---
fs/ceph/addr.c | 24 +++-
fs/ceph/cache.c | 12 +++-
2 files changed, 18 insertions(+), 18 deletions(-)
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -188,7 +188,7 @@ static int ceph_releasepage(struct page
/*
* read a single page, without unlocking it.
*/
-static int readpage_nounlock(struct file *filp, struct page *page)
+static int ceph_do_readpage(struct file *filp, struct page *page)
{
struct inode *inode = file_inode(filp);
struct ceph_inode_info *ci = ceph_inode(inode);
@@ -218,7 +218,7 @@ static int readpage_nounlock(struct file
err = ceph_readpage_from_fscache(inode, page);
if (err == 0)
- goto out;
+ return -EINPROGRESS;
dout("readpage inode %p file %p page %p index %lu\n",
inode, filp, page, page->index);
@@ -248,8 +248,11 @@ out:
static int ceph_readpage(struct file *filp, struct page *page)
{
- int r = readpage_nounlock(filp, page);
- unlock_page(page);
+ int r = ceph_do_readpage(filp, page);
+ if (r != -EINPROGRESS)
+ unlock_page(page);
+ else
+ r = 0;
return r;
}
@@ -1235,7 +1238,7 @@ retry_locked:
goto retry_locked;
r = writepage_nounlock(page, NULL);
if (r < 0)
- goto fail_nosnap;
+ goto fail_unlock;
goto retry_locked;
}
@@ -1263,11 +1266,14 @@ retry_locked:
}
/* we need to read it. */
- r = readpage_nounlock(file, page);
- if (r < 0)
- goto fail_nosnap;
+ r = ceph_do_readpage(file, page);
+ if (r < 0) {
+ if (r == -EINPROGRESS)
+ return -EAGAIN;
+ goto fail_unlock;
+ }
goto retry_locked;
-fail_nosnap:
+fail_unlock:
unlock_page(page);
return r;
}
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -240,13 +240,7 @@ void ceph_fscache_file_set_cookie(struct
}
}
-static void ceph_vfs_readpage_complete(struct page *page, void *data, int
error)
-{
- if (!error)
- SetPageUptodate(page);
-}
-
-static void ceph_vfs_readpage_complete_unlock(struct page *page, void *data,
int error)
+static void ceph_readpage_from_fscache_complete(struct page *page, void *data,
int error)
{
if (!error)
SetPageUptodate(page);
@@ -274,7 +268,7 @@ int ceph_readpage_from_fscache(struct in
return -ENOBUFS;
ret = fscache_read_or_alloc_page(ci->fscache, page,
-ceph_vfs_readpage_complete, NULL,
+ceph_readpage_from_fscache_complete,
NULL,
GFP_KERNEL);
switch (ret) {
@@ -303,7 +297,7 @@ int ceph_readpages_from_fscache(struct i
return -ENOBUFS;
ret = fscache_read_or_alloc_pages(ci->fscache, mapping, pages, nr_pages,
- ceph_vfs_readpage_complete_unlock,
+ ceph_readpage_from_fscache_complete,
NULL, mapping_gfp_mask(mapping));
switch (ret) {
[PATCH 4.9 04/18] crypto: algif_skcipher - only call put_page on referenced and used pages
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Stephan Mueller
commit 445a582738de6802669aeed9c33ca406c23c3b1f upstream.
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface.
Signed-off-by: Stephan Mueller
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/algif_skcipher.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -86,8 +86,13 @@ static void skcipher_free_async_sgls(str
}
sgl = sreq->tsg;
n = sg_nents(sgl);
- for_each_sg(sgl, sg, n, i)
- put_page(sg_page(sg));
+ for_each_sg(sgl, sg, n, i) {
+ struct page *page = sg_page(sg);
+
+ /* some SGs may not have a page mapped */
+ if (page && page_ref_count(page))
+ put_page(page);
+ }
kfree(sreq->tsg);
}
Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC
On Mon, 04 Sep 2017, Takashi Iwai wrote:
> On Mon, 04 Sep 2017 15:37:32 +0200,
> Lee Jones wrote:
> >
> > > +static struct mfd_cell dc_ti_dev[] = {
> > > + {
> > > + .name = "dc_ti_pwrbtn",
> > > + .num_resources = ARRAY_SIZE(power_button_resources),
> > > + .resources = power_button_resources,
> > > + },
> > > + {
> >
> > Place these on the same line.
>
> Does this and ...
>
>
> > > + },
> > > + {
> > > + .name = "dc_ti_region",
> > > + },
> >
> > This should be a one line entry:
> >
> > { .name = "dc_ti_region" },
>
> this match together? The result would be like:
>
> static struct mfd_cell dc_ti_dev[] = {
> {
> .name = "dc_ti_pwrbtn",
> .num_resources = ARRAY_SIZE(power_button_resources),
> .resources = power_button_resources,
> }, {
> .name = "chtdc_ti_adc",
> .num_resources = ARRAY_SIZE(adc_resources),
> .
> }, {.name = "chtdc_ti_region", },
> };
>
> which I find a bit inconsistent.
No, it doesn't.
The single lines need to be on their own.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH 4.4 08/16] CIFS: Fix maximum SMB2 header size
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Pavel Shilovsky commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/cifs/smb2pdu.h +++ b/fs/cifs/smb2pdu.h @@ -82,8 +82,8 @@ #define NUMBER_OF_SMB2_COMMANDS0x0013 -/* BB FIXME - analyze following length BB */ -#define MAX_SMB2_HDR_SIZE 0x78 /* 4 len + 64 hdr + (2*24 wct) + 2 bct + 2 pad */ +/* 4 len + 52 transform hdr + 64 hdr + 56 create rsp */ +#define MAX_SMB2_HDR_SIZE 0x00b0 #define SMB2_PROTO_NUMBER cpu_to_le32(0x424d53fe)
[PATCH 4.4 09/16] CIFS: remove endian related sparse warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
Recent patch had an endian warning ie
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Signed-off-by: Steve French
CC: Ronnie Sahlberg
Acked-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -194,7 +194,7 @@ check_name(struct dentry *direntry, stru
int i;
if (unlikely(direntry->d_name.len >
-tcon->fsAttrInfo.MaxPathNameComponentLength))
+le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
return -ENAMETOOLONG;
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)) {
[PATCH 4.9 01/18] irqchip: mips-gic: SYNC after enabling GIC region
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit 2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream.
A SYNC is required between enabling the GIC region and actually trying
to use it, even if the first access is a read, otherwise its possible
depending on the timing (and in my case depending on the precise
alignment of certain kernel code) to hit CM bus errors on that first
access.
Add the SYNC straight after setting the GIC base.
[paul.bur...@imgtec.com:
Changes later in this series increase our likelihood of hitting this
by reducing the amount of code that runs between enabling the GIC &
accessing it.]
Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support")
Signed-off-by: James Hogan
Signed-off-by: Paul Burton
Acked-by: Marc Zyngier
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17019/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-mips-gic.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -1115,8 +1115,11 @@ static int __init gic_of_init(struct dev
gic_len = resource_size(&res);
}
- if (mips_cm_present())
+ if (mips_cm_present()) {
write_gcr_gic_base(gic_base | CM_GCR_GIC_BASE_GICEN_MSK);
+ /* Ensure GIC region is enabled before trying to access it */
+ __sync();
+ }
gic_present = true;
__gic_init(gic_base, gic_len, cpu_vec, 0, node);
[PATCH 4.4 04/16] ceph: fix readpage from fscache
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Yan, Zheng
commit dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream.
ceph_readpage() unlocks page prematurely prematurely in the case
that page is reading from fscache. Caller of readpage expects that
page is uptodate when it get unlocked. So page shoule get locked
by completion callback of fscache_read_or_alloc_pages()
Signed-off-by: "Yan, Zheng"
Reviewed-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman
---
fs/ceph/addr.c | 24 +++-
fs/ceph/cache.c | 12 +++-
2 files changed, 18 insertions(+), 18 deletions(-)
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -189,7 +189,7 @@ static int ceph_releasepage(struct page
/*
* read a single page, without unlocking it.
*/
-static int readpage_nounlock(struct file *filp, struct page *page)
+static int ceph_do_readpage(struct file *filp, struct page *page)
{
struct inode *inode = file_inode(filp);
struct ceph_inode_info *ci = ceph_inode(inode);
@@ -219,7 +219,7 @@ static int readpage_nounlock(struct file
err = ceph_readpage_from_fscache(inode, page);
if (err == 0)
- goto out;
+ return -EINPROGRESS;
dout("readpage inode %p file %p page %p index %lu\n",
inode, filp, page, page->index);
@@ -249,8 +249,11 @@ out:
static int ceph_readpage(struct file *filp, struct page *page)
{
- int r = readpage_nounlock(filp, page);
- unlock_page(page);
+ int r = ceph_do_readpage(filp, page);
+ if (r != -EINPROGRESS)
+ unlock_page(page);
+ else
+ r = 0;
return r;
}
@@ -1094,7 +1097,7 @@ retry_locked:
goto retry_locked;
r = writepage_nounlock(page, NULL);
if (r < 0)
- goto fail_nosnap;
+ goto fail_unlock;
goto retry_locked;
}
@@ -1122,11 +1125,14 @@ retry_locked:
}
/* we need to read it. */
- r = readpage_nounlock(file, page);
- if (r < 0)
- goto fail_nosnap;
+ r = ceph_do_readpage(file, page);
+ if (r < 0) {
+ if (r == -EINPROGRESS)
+ return -EAGAIN;
+ goto fail_unlock;
+ }
goto retry_locked;
-fail_nosnap:
+fail_unlock:
unlock_page(page);
return r;
}
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -224,13 +224,7 @@ void ceph_fscache_unregister_inode_cooki
fscache_relinquish_cookie(cookie, 0);
}
-static void ceph_vfs_readpage_complete(struct page *page, void *data, int
error)
-{
- if (!error)
- SetPageUptodate(page);
-}
-
-static void ceph_vfs_readpage_complete_unlock(struct page *page, void *data,
int error)
+static void ceph_readpage_from_fscache_complete(struct page *page, void *data,
int error)
{
if (!error)
SetPageUptodate(page);
@@ -259,7 +253,7 @@ int ceph_readpage_from_fscache(struct in
return -ENOBUFS;
ret = fscache_read_or_alloc_page(ci->fscache, page,
-ceph_vfs_readpage_complete, NULL,
+ceph_readpage_from_fscache_complete,
NULL,
GFP_KERNEL);
switch (ret) {
@@ -288,7 +282,7 @@ int ceph_readpages_from_fscache(struct i
return -ENOBUFS;
ret = fscache_read_or_alloc_pages(ci->fscache, mapping, pages, nr_pages,
- ceph_vfs_readpage_complete_unlock,
+ ceph_readpage_from_fscache_complete,
NULL, mapping_gfp_mask(mapping));
switch (ret) {
Re: [PATCH v4] mfd: max77693: Add muic of_compatible in mfd_cell
On Wed, 23 Aug 2017, Maciej Purski wrote: > This patch adds muic of_compatible in order to use the muic device > driver in device tree. > > Signed-off-by: Maciej Purski > --- > v2: > - added muic to documentation > v3: > - removed duplication > v4: > - fixed commit message > > Documentation/devicetree/bindings/mfd/max77693.txt | 6 ++ > drivers/mfd/max77693.c | 5 - > 2 files changed, 10 insertions(+), 1 deletion(-) For my own reference: Acked-for-MFD-by: Lee Jones Please collect the Acks you have and submit a [RESEND]. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 4.4 06/16] cpuset: Fix incorrect memory_pressure control file mapping
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Waiman Long
commit 1c08c22c874ac88799cab1f78c40f46110274915 upstream.
The memory_pressure control file was incorrectly set up without
a private value (0, by default). As a result, this control
file was treated like memory_migrate on read. By adding back the
FILE_MEMORY_PRESSURE private value, the correct memory pressure value
will be returned.
Signed-off-by: Waiman Long
Signed-off-by: Tejun Heo
Fixes: 7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE")
Signed-off-by: Greg Kroah-Hartman
---
kernel/cpuset.c |1 +
1 file changed, 1 insertion(+)
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1910,6 +1910,7 @@ static struct cftype files[] = {
{
.name = "memory_pressure",
.read_u64 = cpuset_read_u64,
+ .private = FILE_MEMORY_PRESSURE,
},
{
[PATCH 4.4 05/16] cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit b339752d054fb32863418452dff350a1086885b1 upstream. When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of @node. The assumption seems that if !NUMA, there shouldn't be more than one node and thus reporting cpu_online_mask regardless of @node is correct. However, that assumption was broken years ago to support DISCONTIGMEM and whether a system has multiple nodes or not is separately controlled by NEED_MULTIPLE_NODES. This means that, on a system with !NUMA && NEED_MULTIPLE_NODES, cpumask_of_node() will report cpu_online_mask for all possible nodes, indicating that the CPUs are associated with multiple nodes which is an impossible configuration. This bug has been around forever but doesn't look like it has caused any noticeable symptoms. However, it triggers a WARN recently added to workqueue to verify NUMA affinity configuration. Fix it by reporting empty cpumask on non-zero nodes if !NUMA. Signed-off-by: Tejun Heo Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/asm-generic/topology.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/include/asm-generic/topology.h +++ b/include/asm-generic/topology.h @@ -48,7 +48,11 @@ #define parent_node(node) ((void)(node),0) #endif #ifndef cpumask_of_node -#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #ifdef CONFIG_NEED_MULTIPLE_NODES +#define cpumask_of_node(node) ((node) == 0 ? cpu_online_mask : cpu_none_mask) + #else +#define cpumask_of_node(node) ((void)node, cpu_online_mask) + #endif #endif #ifndef pcibus_to_node #define pcibus_to_node(bus)((void)(bus), -1)
Re: [PATCH] mm, sparse: fix typo in online_mem_sections
On Tue 05-09-17 12:32:28, Anshuman Khandual wrote: > On 09/04/2017 04:52 PM, Michal Hocko wrote: > > From: Michal Hocko > > > > online_mem_sections accidentally marks online only the first section in > > the given range. This is a typo which hasn't been noticed because I > > haven't tested large 2GB blocks previously. All users of > > Section sizes are normally less than 2GB. Could you please elaborate > why this never got noticed before ? Section size is 128MB which is the default block size as well. So we have one section per block. But if the amount of memory is very large (64GB - see probe_memory_block_size) then we have a 2GB memory blocks so multiple sections per block. -- Michal Hocko SUSE Labs
Re: [PATCH v4 2/3] string.h: add memcpy_and_pad()
On Mon, Aug 14, 2017 at 10:12 PM, Martin Wilck wrote:
> This helper function is useful for the nvme subsystem, and maybe
> others.
>
> Note: the warnings reported by the kbuild test robot for this patch
> are actually generated by the use of CONFIG_PROFILE_ALL_BRANCHES
> together with __FORTIFY_INLINE.
>
> Signed-off-by: Martin Wilck
> ---
> #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) &&
> defined(CONFIG_FORTIFY_SOURCE)
> @@ -395,4 +396,33 @@ __FORTIFY_INLINE char *strcpy(char *p, const char *q)
>
> #endif
>
> +/**
> + * memcpy_and_pad - Copy one buffer to another with padding
> + * @dest: Where to copy to
> + * @dest_len: The destination buffer size
> + * @src: Where to copy from
> + * @count: The number of bytes to copy
> + * @pad: Character to use for padding if space is left in destination.
> + */
> +__FORTIFY_INLINE void memcpy_and_pad(void *dest, size_t dest_len,
> +const void *src, size_t count, int pad)
> +{
This is causing compile-time warnings for me:
In file included from /git/arm-soc/arch/x86/include/asm/string.h:2:0,
from /git/arm-soc/include/linux/string.h:18,
from /git/arm-soc/arch/x86/include/asm/page_32.h:34,
from /git/arm-soc/arch/x86/include/asm/page.h:13,
from /git/arm-soc/arch/x86/include/asm/thread_info.h:11,
from /git/arm-soc/include/linux/thread_info.h:37,
from /git/arm-soc/arch/x86/include/asm/preempt.h:6,
from /git/arm-soc/include/linux/preempt.h:80,
from /git/arm-soc/include/linux/spinlock.h:50,
from /git/arm-soc/include/linux/seqlock.h:35,
from /git/arm-soc/include/linux/time.h:5,
from /git/arm-soc/include/linux/stat.h:18,
from /git/arm-soc/include/linux/module.h:10,
from /git/arm-soc/drivers/md/dm-integrity.c:9:
/git/arm-soc/arch/x86/include/asm/string_32.h:196:25: error:
'__memcpy' is static but used in inline function 'memcpy_and_pad'
which is not static [-Werror]
#define memcpy(t, f, n) __memcpy((t), (f), (n))
^~~~
/git/arm-soc/include/linux/string.h:466:3: note: in expansion of macro 'memcpy'
^
/git/arm-soc/arch/x86/include/asm/string_32.h:196:25: error:
'__memcpy' is static but used in inline function 'memcpy_and_pad'
which is not static [-Werror]
#define memcpy(t, f, n) __memcpy((t), (f), (n))
^~~~
The problem is the use of __FORTIFY_INLINE outside of the #ifdef
section above it.
I used an ugly local workaround, duplicating the function with a
'static inline' variant
in an #else block. Alternatively we could add an extern version in
lib/string.c for the
non-fortified case.
Arnd
[PATCH 4.4 03/16] i2c: ismt: Return EMSGSIZE for block reads with bogus length
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit ba201c4f5ebe13d7819081756378777d8153f23e upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -339,8 +339,10 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: + if (desc->rxbytes != dma_buffer[0] + 1) + return -EMSGSIZE; + memcpy(data->block, dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 4.4 02/16] i2c: ismt: Dont duplicate the receive length for block reads
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -339,8 +339,8 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: - memcpy(&data->block[1], dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes; + memcpy(data->block, dma_buffer, desc->rxbytes); + data->block[0] = desc->rxbytes - 1; break; } return 0;
Re: [PATCH v2] drivers/mailbox: Add Aspeed mailbox driver
On Tue, 2017-09-05 at 08:25 +0200, Greg KH wrote: > On Tue, Sep 05, 2017 at 09:37:19AM +1000, Cyril Bur wrote: > > On Mon, 2017-09-04 at 20:13 +0530, Jassi Brar wrote: > > > On Mon, Sep 4, 2017 at 12:47 PM, Cyril Bur wrote: > > > > Hi, > > > > > > > > I haven't heard anything about this driver. I'm trying to interpret if > > > > the silence is because there is something fundamentally wrong with the > > > > driver or is it because it doesn't use any of the mailbox > > > > infrastructure it is being ignored. > > > > > > > > > > Its the latter. > > > > Great! Thanks for your response, I'll resend it under char/misc. > > Wait, no, please use the mailbox infrastructure for this, making a > one-off char/misc driver isn't ok when there is a framework for you to > use. > Thanks very much for your response. Yes you're absolutely correct, I'll send it to drivers/mailbox. I look forward to working more closely with Jassi. I'll be sure to fully and completely exploit all the features of this mailbox framework. Looking forward to continued development, Thanks very much to all involved, Cyril > thanks, > > greg k-h
[PATCH 4.4 11/16] xfrm: policy: check policy direction value
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vladis Dronov
commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint
address(es)")
Reported-by: "bo Zhang"
Signed-off-by: Vladis Dronov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_policy.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3275,9 +3275,15 @@ int xfrm_migrate(const struct xfrm_selec
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
+ /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
+ if (dir >= XFRM_POLICY_MAX) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
[PATCH 3.18 7/9] xfrm: policy: check policy direction value
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Vladis Dronov
commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint
address(es)")
Reported-by: "bo Zhang"
Signed-off-by: Vladis Dronov
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_policy.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3248,9 +3248,15 @@ int xfrm_migrate(const struct xfrm_selec
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
+ /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
+ if (dir >= XFRM_POLICY_MAX) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
[PATCH 4.4 01/16] irqchip: mips-gic: SYNC after enabling GIC region
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit 2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream.
A SYNC is required between enabling the GIC region and actually trying
to use it, even if the first access is a read, otherwise its possible
depending on the timing (and in my case depending on the precise
alignment of certain kernel code) to hit CM bus errors on that first
access.
Add the SYNC straight after setting the GIC base.
[paul.bur...@imgtec.com:
Changes later in this series increase our likelihood of hitting this
by reducing the amount of code that runs between enabling the GIC &
accessing it.]
Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support")
Signed-off-by: James Hogan
Signed-off-by: Paul Burton
Acked-by: Marc Zyngier
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17019/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-mips-gic.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -915,8 +915,11 @@ static int __init gic_of_init(struct dev
gic_len = resource_size(&res);
}
- if (mips_cm_present())
+ if (mips_cm_present()) {
write_gcr_gic_base(gic_base | CM_GCR_GIC_BASE_GICEN_MSK);
+ /* Ensure GIC region is enabled before trying to access it */
+ __sync();
+ }
gic_present = true;
__gic_init(gic_base, gic_len, cpu_vec, 0, node);
[PATCH 3.18 1/9] i2c: ismt: Dont duplicate the receive length for block reads
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream. According to Table 15-14 of the C2000 EDS (Intel doc #510524) the rx data pointed to by the descriptor dptr contains the byte count. desc->rxbytes reports all bytes read on the wire, including the "byte count" byte. So if a device sends 4 bytes in response to a block read, on the wire and in the DMA buffer we see: count data1 data2 data3 data4 0x04 0xde 0xad 0xbe 0xef That's what we want to return in data->block to the next level. Instead we were actually prefixing that with desc->rxbytes: bad count count data1 data2 data3 data4 0x05 0x04 0xde 0xad 0xbe 0xef This was discovered while developing a BMC solution relying on the ipmi_ssif.c driver which was trying to interpret the bogus length field as part of the IPMI response. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -340,8 +340,8 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: - memcpy(&data->block[1], dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes; + memcpy(data->block, dma_buffer, desc->rxbytes); + data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH 3.18 5/9] CIFS: remove endian related sparse warning
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
Recent patch had an endian warning ie
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Signed-off-by: Steve French
CC: Ronnie Sahlberg
Acked-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -194,7 +194,7 @@ check_name(struct dentry *direntry, stru
int i;
if (unlikely(direntry->d_name.len >
-tcon->fsAttrInfo.MaxPathNameComponentLength))
+le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
return -ENAMETOOLONG;
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)) {
答复: 答复: [PATCH v4] mfd: Add support for RTS5250S power saving
> > +static void rts5250_set_l1off_cfg_sub_d0(struct rtsx_pcr *pcr, int
> > +active) {
> > + struct rtsx_cr_option *option = &(pcr->option);
> > +
> > + u32 interrupt = rtsx_pci_readl(pcr, RTSX_BIPR);
> > + int card_exist = (interrupt & SD_EXIST) | (interrupt & MS_EXIST);
> > + int aspm_L1_1, aspm_L1_2;
> > + u8 val = 0;
>
> No need to pre-allocate.
All of my responses should now be quotes, but they are not.
This makes replying to your messages difficult.
Please fix your editor.
> If val is not pre-allocated, what will the val be if it is not assigned
> before using?
You do not use it before assigning it.
If aspm_L1_1 == 0 && aspm_L1_2 == 0, the val will be used before assigned.
> > + aspm_L1_1 = rtsx_check_dev_flag(pcr, ASPM_L1_1_EN);
> > + aspm_L1_2 = rtsx_check_dev_flag(pcr, ASPM_L1_2_EN);
> > +
> > + if (active) {
> > + /* run, latency: 60us */
> > + if (aspm_L1_1)
> > + val = option->ltr_l1off_snooze_sspwrgate;
> > + } else {
> > + /* l1off, latency: 300us */
> > + if (aspm_L1_2)
> > + val = option->ltr_l1off_sspwrgate;
> > + }
> > +
> > + if (aspm_L1_1 || aspm_L1_2) {
> > + if (rtsx_check_dev_flag(pcr,
> > + LTR_L1SS_PWR_GATE_CHECK_CARD_EN)) {
> > + if (card_exist)
> > + val &= ~L1OFF_MBIAS2_EN_5250;
> > + else
> > + val |= L1OFF_MBIAS2_EN_5250;
> > + }
> > + }
> > + rtsx_set_l1off_sub(pcr, val);
> > +}
> > +
> > static const struct pcr_ops rts524a_pcr_ops = {
> > .write_phy = rts524a_write_phy,
> > .read_phy = rts524a_read_phy,
> > @@ -473,11 +617,16 @@ static int rts524a_extra_init_hw(struct rtsx_pcr *pcr)
> > .card_power_off = rtsx_base_card_power_off,
> > .switch_output_voltage = rtsx_base_switch_output_voltage,
> > .force_power_down = rtsx_base_force_power_down,
> > + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> > + .set_aspm = rts5249_set_aspm,
> > };
> >
> > void rts524a_init_params(struct rtsx_pcr *pcr) {
> > rts5249_init_params(pcr);
> > + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> > + pcr->option.ltr_l1off_snooze_sspwrgate =
> > + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
> >
> > pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> > pcr->ops = &rts524a_pcr_ops;
> > @@ -576,11 +725,16 @@ static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
> > .card_power_off = rtsx_base_card_power_off,
> > .switch_output_voltage = rts525a_switch_output_voltage,
> > .force_power_down = rtsx_base_force_power_down,
> > + .set_l1off_cfg_sub_d0 = rts5250_set_l1off_cfg_sub_d0,
> > + .set_aspm = rts5249_set_aspm,
> > };
> >
> > void rts525a_init_params(struct rtsx_pcr *pcr) {
> > rts5249_init_params(pcr);
> > + pcr->option.ltr_l1off_sspwrgate = LTR_L1OFF_SSPWRGATE_5250_DEFAULT;
> > + pcr->option.ltr_l1off_snooze_sspwrgate =
> > + LTR_L1OFF_SNOOZE_SSPWRGATE_5250_DEFAULT;
> >
> > pcr->reg_pm_ctrl3 = RTS524A_PM_CTRL3;
> > pcr->ops = &rts525a_pcr_ops;
> > diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index
> > a0ac89d..50a6e67 100644
> > --- a/drivers/mfd/rtsx_pcr.c
> > +++ b/drivers/mfd/rtsx_pcr.c
> > @@ -79,6 +79,131 @@ static inline void rtsx_pci_disable_aspm(struct
> > rtsx_pcr *pcr)
> > 0xFC, 0);
> > }
> >
> > +int rtsx_comm_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> > + rtsx_pci_write_register(pcr, MSGTXDATA0, 0xFF, (u8) (latency &
> > +0xFF));
>
> What is (the first) 0xFF?
>
> 0xFF is just 8 bit mask.
I mean the first one.
The first 0xFF is also 8 bit mask.
> > + rtsx_pci_write_register(pcr, MSGTXDATA1,
> > + 0xFF, (u8)((latency >> 8) & 0xFF));
> > + rtsx_pci_write_register(pcr, MSGTXDATA2,
> > + 0xFF, (u8)((latency >> 16) & 0xFF));
> > + rtsx_pci_write_register(pcr, MSGTXDATA3,
> > + 0xFF, (u8)((latency >> 24) & 0xFF));
> > + rtsx_pci_write_register(pcr, LTR_CTL, LTR_TX_EN_MASK |
> > + LTR_LATENCY_MODE_MASK, LTR_TX_EN_1 | LTR_LATENCY_MODE_SW);
> > +
> > + return 0;
> > +}
> > +
> > +int rtsx_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency) {
> > + if (pcr->ops->set_ltr_latency)
> > + return pcr->ops->set_ltr_latency(pcr, latency);
> > + else
> > + return rtsx_comm_set_ltr_latency(pcr, latency); }
> > +
> > +static void rtsx_comm_set_aspm(struct rtsx_pcr *pcr, bool enable) {
> > + struct rtsx_cr_option *option = &pcr->option;
> > +
> > + if (pcr->aspm_enabled == enable)
> > + return;
> > +
> > + if (option->dev_aspm_mode == DEV_ASPM_DYNAMIC) {
> > + if (enable)
> > + rtsx_pci_enable_aspm(pcr);
> > + else
> > + rtsx_pci_disable_aspm(pcr);
> > + } else if (option->dev_aspm_mode == DEV_AS
[PATCH 3.18 4/9] CIFS: Fix maximum SMB2 header size
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Pavel Shilovsky commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream. Currently the maximum size of SMB2/3 header is set incorrectly which leads to hanging of directory listing operations on encrypted SMB3 connections. Fix this by setting the maximum size to 170 bytes that is calculated as RFC1002 length field size (4) + transform header size (52) + SMB2 header size (64) + create response size (56). Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/cifs/smb2pdu.h +++ b/fs/cifs/smb2pdu.h @@ -82,8 +82,8 @@ #define NUMBER_OF_SMB2_COMMANDS0x0013 -/* BB FIXME - analyze following length BB */ -#define MAX_SMB2_HDR_SIZE 0x78 /* 4 len + 64 hdr + (2*24 wct) + 2 bct + 2 pad */ +/* 4 len + 52 transform hdr + 64 hdr + 56 create rsp */ +#define MAX_SMB2_HDR_SIZE 0x00b0 #define SMB2_PROTO_NUMBER __constant_cpu_to_le32(0x424d53fe)
[PATCH 3.18 2/9] i2c: ismt: Return EMSGSIZE for block reads with bogus length
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Stephen Douthit commit ba201c4f5ebe13d7819081756378777d8153f23e upstream. Compare the number of bytes actually seen on the wire to the byte count field returned by the slave device. Previously we just overwrote the byte count returned by the slave with the real byte count and let the caller figure out if the message was sane. Signed-off-by: Stephen Douthit Tested-by: Dan Priamo Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-ismt.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -340,8 +340,10 @@ static int ismt_process_desc(const struc break; case I2C_SMBUS_BLOCK_DATA: case I2C_SMBUS_I2C_BLOCK_DATA: + if (desc->rxbytes != dma_buffer[0] + 1) + return -EMSGSIZE; + memcpy(data->block, dma_buffer, desc->rxbytes); - data->block[0] = desc->rxbytes - 1; break; } return 0;
[PATCH] staging: rts5208: fix gcc-8 logic error warning
As gcc-8 points out, the bit mask check makes no sense here:
drivers/staging/rts5208/sd.c: In function 'ext_sd_send_cmd_get_rsp':
drivers/staging/rts5208/sd.c:4130:25: error: bitwise comparison always
evaluates to true [-Werror=tautological-compare]
However, the code is even more bogus, as we have already
checked for the SD_RSP_TYPE_R0 case earlier in the function
and returned success. As seen in the mmc/sd driver core,
SD_RSP_TYPE_R0 means "no response" anyway, so checking for
a particular response would not help either.
This just removes the nonsensical code to get rid of the
warning.
Signed-off-by: Arnd Bergmann
---
drivers/staging/rts5208/sd.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index 4033a2cf7ac9..d548bc695f9e 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -4125,12 +4125,6 @@ int ext_sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8
cmd_idx, u32 arg,
rtsx_trace(chip);
return STATUS_FAIL;
}
-
- } else if (rsp_type == SD_RSP_TYPE_R0) {
- if ((ptr[3] & 0x1E) != 0x03) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
}
}
}
--
2.9.0
