Re: VLA removal (was Re: [RFC 2/2] lustre: use VLA_SAFE)
On 7 March 2018 at 13:09, Linus Torvalds wrote:
> On Wed, Mar 7, 2018 at 9:37 AM, Kees Cook wrote:
>>
>> Building with -Wvla, I see 209 unique locations reported in 60 directories:
>> http://paste.ubuntu.com/p/srQxwPQS9s/
>
> Ok, that's not so bad. Maybe Greg could even add it to one of those
> things he encourages new people to do?
>
> Because at least *some* of them are pretty trivial. For example,
> looking at the core code, I was surprised to see something in
> lib/btree.c
Some are probably just the issue of technically having a VLA that's
not really a VLA:
static const int size = 5;
void foo(void) {
int x[size];
}
% gcc -c -Wvla foo.c
foo.c: In function ‘foo’:
foo.c:4:3: warning: ISO C90 forbids variable length array ‘x’ [-Wvla]
int x[size];
^~~
I don't really understand why the C standard didn't make `static
const` declarations usable as constant expressions like C++. They made
the pointer conversions more painful too.
It would be nice to get rid of those cases to use -Werror=vla though.
RE: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()
+Cc Miguel Ojeda
> > > +({
> > > \
> > > + struct efi_runtime_work efi_rts_work; \
> > > + \
> > > + INIT_WORK_ONSTACK(&efi_rts_work.work, efi_call_rts);\
> > > + efi_rts_work.func = _rts; \
> > > + efi_rts_work.arg1 = _arg1; \
> > > + efi_rts_work.arg2 = _arg2; \
> > > + efi_rts_work.arg3 = _arg3; \
> > > + efi_rts_work.arg4 = _arg4; \
> > > + efi_rts_work.arg5 = _arg5; \
> > > + /* \
> > > + * queue_work() returns 0 if work was already on queue, \
> > > + * _ideally_ this should never happen. \
> > > + */ \
> > > + if (queue_work(efi_rts_wq, &efi_rts_work.work))
> > \
> > > + flush_work(&efi_rts_work.work);
> > \
> > > + else\
> > > + BUG(); \
> >
> > So failure to queue that work is such a critical problem that we need
> > to BUG() and can't possibly continue and shoult not attempt recovery at all?
> >
>
> I think it's not critical, we can just return error status.
> I think the problem in itself is not at all critical but when I initially
> thought about
> why the problem could have occurred, it sounded like one i.e. ideally (if the
> system is running fine) we should always be able to queue work. Failure to
> queue
> means that the previous work is already on queue and that shouldn't be the
> case.
> So, thought, maybe something bad had happened already (just doubtful).
>
> But, I see your point. BUG() sounds more like an over kill. Instead of fixing
> an
> existing problem, this patch could completely take down the system.
>
> > IOW, we should always strive to fail gracefully and not shit in pants
> > at the first sign of trouble.
> >
>
> Yes, that makes sense. I will remove BUG() in V3 (in the two places that I
> introduced).
>
> > Even checkpatch warns here:
> >
> > WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> > rather than BUG() or BUG_ON()
> > #184: FILE: drivers/firmware/efi/runtime-wrappers.c:92:
> > + BUG(); \
> >
>
> Sure! I will fix this
>
> >
> > and by looking at the other output, you should run your patches
> > through checkpatch. Some of the things make sense like:
> >
> > WARNING: quoted string split across lines
> > #97: FILE: drivers/firmware/efi/efi.c:341:
> > + pr_err("Failed to create efi_rts_workqueue, EFI runtime
> > services "
> > + "disabled.\n");
> >
> > for example.
> >
>
> I will fix this one too.
>
> Another warning by checkpatch is "use of in_atomic() in drivers code"
> Do you think it's OK to check if were are "in_atomic()" in drivers code.
> I wasn't able to decide on other alternative, if possible, could you please
> suggest
> one?
>
> Regards,
> Sai
Re: [PATCH] clk: aspeed: Prevent reset if clock is enabled
On Thu, Mar 8, 2018 at 11:42 AM, Joel Stanley wrote:
>> + /* Only reset/enable/unreset if clock is stopped */
>> + regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, ®);
>> + if (!(reg & clk))
>> + return 0;
>
> This doesn't generalise to all of the clocks, as some clocks use set
> to disable. Perhaps we could do something like this:
>
>/* Only reset/enable/unreset if clock is stopped. The LPC clock
> on ast2500 has issues otherwise */
>enval = (gate->flags & CLK_GATE_SET_TO_DISABLE) ? 0 : clk;
>regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, ®);
>if ((reg & clk) == enval) {
>spin_unlock_irqrestore(gate->lock, flags);
>return 0;
>}
>
> I think we should also do this operation under the lock.
>
> Please cc Ryan Chen so he can confirm that
> this workaround is valid, and credit Lei who spent a lot of time
> investigating this issue. Perhaps "Root-caused-by".
>
The code has aspeed_clk_is_enabled() already, why not just:
if (aspeed_clk_is_enabled(hw))
return 0;
[PATCH AUTOSEL for 4.4 032/101] NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete()
From: Benjamin Coddington
[ Upstream commit 43b7d964ed30dbca5c83c90cb010985b429ec4f9 ]
Commit a7d42ddb3099727f58366fa006f850a219cce6c8 ("nfs: add mirroring
support to pgio layer") moved pg_cleanup out of the path when there was
non-sequental I/O that needed to be flushed. The result is that for
layouts that have more than one layout segment per file, the pg_lseg is not
cleared, so we can end up hitting the WARN_ON_ONCE(req_start >= seg_end) in
pnfs_generic_pg_test since the pg_lseg will be pointing to that
previously-flushed layout segment.
Signed-off-by: Benjamin Coddington
Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
fs/nfs/pagelist.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 8ebfdd00044b..4bdc2fc86280 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -1273,8 +1273,10 @@ void nfs_pageio_cond_complete(struct
nfs_pageio_descriptor *desc, pgoff_t index)
mirror = &desc->pg_mirrors[midx];
if (!list_empty(&mirror->pg_list)) {
prev = nfs_list_entry(mirror->pg_list.prev);
- if (index != prev->wb_index + 1)
- nfs_pageio_complete_mirror(desc, midx);
+ if (index != prev->wb_index + 1) {
+ nfs_pageio_complete(desc);
+ break;
+ }
}
}
}
--
2.14.1
[PATCH AUTOSEL for 4.4 034/101] e1000e: fix timing for 82579 Gigabit Ethernet controller
From: Bernd Faust
[ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ]
After an upgrade to Linux kernel v4.x the hardware timestamps of the
82579 Gigabit Ethernet Controller are different than expected.
The values that are being read are almost four times as big as before
the kernel upgrade.
The difference is that after the upgrade the driver sets the clock
frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
confirmed that the correct frequency for this network adapter is 96MHz.
Signed-off-by: Bernd Faust
Acked-by: Sasha Neftin
Acked-by: Jacob Keller
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 5205f1ebe381..e356e9187e84 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3526,6 +3526,12 @@ s32 e1000e_get_base_timinca(struct e1000_adapter
*adapter, u32 *timinca)
switch (hw->mac.type) {
case e1000_pch2lan:
+ /* Stable 96MHz frequency */
+ incperiod = INCPERIOD_96MHz;
+ incvalue = INCVALUE_96MHz;
+ shift = INCVALUE_SHIFT_96MHz;
+ adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz;
+ break;
case e1000_pch_lpt:
if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
/* Stable 96MHz frequency */
--
2.14.1
[PATCH AUTOSEL for 4.4 035/101] ALSA: hda - Fix headset microphone detection for ASUS N551 and N751
From: Mikhail Paulyshka
[ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]
Headset microphone does not work out of the box on ASUS Nx51
laptops. This patch fixes it.
Patch tested on Asus N551 laptop. Asus N751 part is not tested, but
according to [1] this laptop uses the same audiosystem.
1. https://bugzilla.kernel.org/show_bug.cgi?id=117781
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
Signed-off-by: Mikhail Paulyshka
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/pci/hda/patch_realtek.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b302d056e5d3..777db644e735 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6701,6 +6701,7 @@ enum {
ALC668_FIXUP_DELL_DISABLE_AAMIX,
ALC668_FIXUP_DELL_XPS13,
ALC662_FIXUP_ASUS_Nx50,
+ ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
ALC668_FIXUP_ASUS_Nx51,
};
@@ -6948,14 +6949,21 @@ static const struct hda_fixup alc662_fixups[] = {
.chained = true,
.chain_id = ALC662_FIXUP_BASS_1A
},
+ [ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_headset_mode_alc668,
+ .chain_id = ALC662_FIXUP_BASS_CHMAP
+ },
[ALC668_FIXUP_ASUS_Nx51] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
- {0x1a, 0x90170151}, /* bass speaker */
+ { 0x19, 0x03a1913d }, /* use as headphone mic, without
its own jack detect */
+ { 0x1a, 0x90170151 }, /* bass speaker */
+ { 0x1b, 0x03a1113c }, /* use as headset mic, without
its own jack detect */
{}
},
.chained = true,
- .chain_id = ALC662_FIXUP_BASS_CHMAP,
+ .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
},
};
--
2.14.1
[PATCH AUTOSEL for 4.4 036/101] IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow
From: Feras Daoud
[ Upstream commit 3e31a490e01a6e67cbe9f6e1df2f3ff0fbf48972 ]
Before calling ipoib_stop, rtnl_lock should be taken, then
the flow clears the IPOIB_FLAG_ADMIN_UP and IPOIB_FLAG_OPER_UP
flags, and waits for mcast completion if IPOIB_MCAST_FLAG_BUSY
is set.
On the other hand, the flow of multicast join task initializes
a mcast completion, sets the IPOIB_MCAST_FLAG_BUSY and calls
ipoib_mcast_join. If IPOIB_FLAG_OPER_UP flag is not set, this
call returns EINVAL without setting the mcast completion and
leads to a deadlock.
ipoib_stop |
| |
clear_bit(IPOIB_FLAG_ADMIN_UP) |
| |
Context Switch |
| ipoib_mcast_join_task
| |
| spin_lock_irq(lock)
| |
| init_completion(mcast)
| |
| set_bit(IPOIB_MCAST_FLAG_BUSY)
| |
| Context Switch
| |
clear_bit(IPOIB_FLAG_OPER_UP) |
| |
spin_lock_irqsave(lock) |
| |
Context Switch |
| ipoib_mcast_join
| return (-EINVAL)
| |
| spin_unlock_irq(lock)
| |
| Context Switch
| |
ipoib_mcast_dev_flush |
wait_for_completion(mcast) |
ipoib_stop will wait for mcast completion for ever, and will
not release the rtnl_lock. As a result panic occurs with the
following trace:
[13441.639268] Call Trace:
[13441.640150] [] schedule+0x29/0x70
[13441.641038] [] schedule_timeout+0x239/0x2d0
[13441.641914] [] ? complete+0x47/0x50
[13441.642765] [] ? flush_workqueue_prep_pwqs+0x16d/0x200
[13441.643580] [] wait_for_completion+0x116/0x170
[13441.644434] [] ? wake_up_state+0x20/0x20
[13441.645293] [] ipoib_mcast_dev_flush+0x150/0x190
[ib_ipoib]
[13441.646159] [] ipoib_ib_dev_down+0x37/0x60 [ib_ipoib]
[13441.647013] [] ipoib_stop+0x75/0x150 [ib_ipoib]
Fixes: 08bc327629cb ("IB/ipoib: fix for rare multicast join race condition")
Signed-off-by: Feras Daoud
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 5580ab0b5781..682a69daac5d 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -473,6 +473,9 @@ static int ipoib_mcast_join(struct net_device *dev, struct
ipoib_mcast *mcast)
!test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))
return -EINVAL;
+ init_completion(&mcast->done);
+ set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+
ipoib_dbg_mcast(priv, "joining MGID %pI6\n", mcast->mcmember.mgid.raw);
rec.mgid = mcast->mcmember.mgid;
@@ -631,8 +634,6 @@ void ipoib_mcast_join_task(struct work_struct *work)
if (mcast->backoff == 1 ||
time_after_eq(jiffies, mcast->delay_until)) {
/* Found the next unjoined group */
- init_completion(&mcast->done);
- set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
if (ipoib_mcast_join(dev, mcast)) {
spin_unlock_irq(&priv->lock);
return;
@@ -652,11 +653,9 @@ void ipoib_mcast_join_task(struct work_struct *work)
queue_delayed_work(priv->wq, &priv->mcast_task,
delay_until - jiffies);
}
- if (mcast) {
- init_completion(&mcast->done);
- set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+ if (mcast)
ipoib_mcast_join(dev, mcast);
- }
+
spin_unlock_irq(&priv->lock);
}
--
2.14.1
[PATCH AUTOSEL for 4.4 031/101] md/raid10: wait up frozen array in handle_write_completed
From: Guoqing Jiang
[ Upstream commit cf25ae78fc50010f66b9be945017796da34c434d ]
Since nr_queued is changed, we need to call wake_up here
if the array is already frozen and waiting for condition
"nr_pending == nr_queued + extra" to be true.
And commit 824e47daddbf ("RAID1: avoid unnecessary spin
locks in I/O barrier code") which has already added the
wake_up for raid1.
Signed-off-by: Guoqing Jiang
Reviewed-by: NeilBrown
Signed-off-by: Shaohua Li
Signed-off-by: Sasha Levin
---
drivers/md/raid10.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index a8a86d450d76..05548af8df6f 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2698,6 +2698,11 @@ static void handle_write_completed(struct r10conf *conf,
struct r10bio *r10_bio)
list_add(&r10_bio->retry_list, &conf->bio_end_io_list);
conf->nr_queued++;
spin_unlock_irq(&conf->device_lock);
+ /*
+* In case freeze_array() is waiting for condition
+* nr_pending == nr_queued + extra to be true.
+*/
+ wake_up(&conf->wait_barrier);
md_wakeup_thread(conf->mddev->thread);
} else {
if (test_bit(R10BIO_WriteError,
--
2.14.1
[PATCH AUTOSEL for 4.4 037/101] IB/ipoib: Update broadcast object if PKey value was changed in index 0
From: Feras Daoud
[ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ]
Update the broadcast address in the priv->broadcast object when the
Pkey value changes in index 0, otherwise the multicast GID value will
keep the previous value of the PKey, and will not be updated.
This leads to interface state down because the interface will keep the
old PKey value.
For example, in SR-IOV environment, if the PF changes the value of PKey
index 0 for one of the VFs, then the VF receives PKey change event that
triggers heavy flush. This flush calls update_parent_pkey that update the
broadcast object and its relevant members. If in this case the multicast
GID will not be updated, the interface state will be down.
Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization
environments")
Signed-off-by: Feras Daoud
Signed-off-by: Erez Shitrit
Reviewed-by: Alex Vesker
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index d3f0a384faad..f6b06729f4ea 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -945,6 +945,19 @@ static inline int update_parent_pkey(struct ipoib_dev_priv
*priv)
*/
priv->dev->broadcast[8] = priv->pkey >> 8;
priv->dev->broadcast[9] = priv->pkey & 0xff;
+
+ /*
+* Update the broadcast address in the priv->broadcast object,
+* in case it already exists, otherwise no one will do that.
+*/
+ if (priv->broadcast) {
+ spin_lock_irq(&priv->lock);
+ memcpy(priv->broadcast->mcmember.mgid.raw,
+ priv->dev->broadcast + 4,
+ sizeof(union ib_gid));
+ spin_unlock_irq(&priv->lock);
+ }
+
return 0;
}
--
2.14.1
[PATCH v5] usb: core: Add "quirks" parameter for usbcore
Trying quirks in usbcore needs to rebuild the driver or the entire kernel if it's builtin. It can save a lot of time if usbcore has similar ability like "usbhid.quirks=" and "usb-storage.quirks=". Rename the original quirk detection function to "static" as we introduce this new "dynamic" function. Now users can use "usbcore.quirks=" as short term workaround before the next kernel release. Also, the quirk parameter can XOR the builtin quirks for debugging purpose. This is inspired by usbhid and usb-storage. Signed-off-by: Kai-Heng Feng --- v5: Use module_param_cb() to get notified when parameter changes. Replace linked list with array. v4: Use kmalloc() to reduce memory usage. Remove tolower() so we can use capital character in the future. v3: Stop overridding static quirks. Use XOR for dynamic quirks. Save parsed quirk as a list to avoid parsing quirk table everytime. v2: Use in-kernel tolower() function. Documentation/admin-guide/kernel-parameters.txt | 55 drivers/usb/core/quirks.c | 177 +++- drivers/usb/core/usb.c | 1 + drivers/usb/core/usb.h | 1 + 4 files changed, 229 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1d1d53f85ddd..70a7398c20e2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4368,6 +4368,61 @@ usbcore.nousb [USB] Disable the USB subsystem + usbcore.quirks= + [USB] A list of quirks entries to supplement or + override the built-in usb core quirk list. List + entries are separated by commas. Each entry has + the form VID:PID:Flags where VID and PID are Vendor + and Product ID values (4-digit hex numbers) and + Flags is a set of characters, each corresponding + to a common usb core quirk flag as follows: + a = USB_QUIRK_STRING_FETCH_255 (string + descriptors must not be fetched using + a 255-byte read); + b = USB_QUIRK_RESET_RESUME (device can't resume + correctly so reset it instead); + c = USB_QUIRK_NO_SET_INTF (device can't handle + Set-Interface requests); + d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't + handle its Configuration or Interface + strings); + e = USB_QUIRK_RESET (device can't be reset + (e.g morph devices), don't use reset); + f = USB_QUIRK_HONOR_BNUMINTERFACES (device has + more interface descriptions than the + bNumInterfaces count, and can't handle + talking to these interfaces); + g = USB_QUIRK_DELAY_INIT (device needs a pause + during initialization, after we read + the device descriptor); + h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For + high speed and super speed interrupt + endpoints, the USB 2.0 and USB 3.0 spec + require the interval in microframes (1 + microframe = 125 microseconds) to be + calculated as interval = 2 ^ + (bInterval-1). + Devices with this quirk report their + bInterval as the result of this + calculation instead of the exponent + variable used in the calculation); + i = USB_QUIRK_DEVICE_QUALIFIER (device can't + handle device_qualifier descriptor + requests); + j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device + generates spurious wakeup, ignore + remote wakeup capability); + k = USB_QUIRK_NO_LPM (device can't handle Link + Power Management); + l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL +
[PATCH AUTOSEL for 4.4 041/101] ASoC: Intel: Skylake: Uninitialized variable in probe_codec()
From: Dan Carpenter
[ Upstream commit e6a33532affd14c12688c0e9b2e773e8b2550f3b ]
My static checker complains that if snd_hdac_bus_get_response() returns
-EIO then "res" is uninitialized. Fix this by initializing it to -1 so
that the error is handled correctly.
Fixes: d8c2dab8381d ("ASoC: Intel: Add Skylake HDA audio driver")
Signed-off-by: Dan Carpenter
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/skylake/skl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index b4844f78266f..f6c3be192cc9 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -280,7 +280,7 @@ static int probe_codec(struct hdac_ext_bus *ebus, int addr)
struct hdac_bus *bus = ebus_to_hbus(ebus);
unsigned int cmd = (addr << 28) | (AC_NODE_ROOT << 20) |
(AC_VERB_PARAMETERS << 8) | AC_PAR_VENDOR_ID;
- unsigned int res;
+ unsigned int res = -1;
mutex_lock(&bus->cmd_mutex);
snd_hdac_bus_send_cmd(bus, cmd);
--
2.14.1
[PATCH AUTOSEL for 4.4 038/101] HSI: ssi_protocol: double free in ssip_pn_xmit()
From: Dan Carpenter
[ Upstream commit 3026050179a3a9a6f5c892c414b5e36ecf092081 ]
If skb_pad() fails then it frees skb and we don't need to free it again
at the end of the function.
Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol")
Signed-off-by: Dan Carpenter
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
---
drivers/hsi/clients/ssi_protocol.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hsi/clients/ssi_protocol.c
b/drivers/hsi/clients/ssi_protocol.c
index a38af68cf326..0a0628d11c0b 100644
--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -976,7 +976,7 @@ static int ssip_pn_xmit(struct sk_buff *skb, struct
net_device *dev)
goto drop;
/* Pad to 32-bits - FIXME: Revisit*/
if ((skb->len & 3) && skb_pad(skb, 4 - (skb->len & 3)))
- goto drop;
+ goto inc_dropped;
/*
* Modem sends Phonet messages over SSI with its own endianess...
@@ -1028,8 +1028,9 @@ static int ssip_pn_xmit(struct sk_buff *skb, struct
net_device *dev)
drop2:
hsi_free_msg(msg);
drop:
- dev->stats.tx_dropped++;
dev_kfree_skb(skb);
+inc_dropped:
+ dev->stats.tx_dropped++;
return 0;
}
--
2.14.1
[PATCH AUTOSEL for 4.4 039/101] IB/mlx4: Take write semaphore when changing the vma struct
From: Maor Gottlieb
[ Upstream commit 22c3653d04bd0c67b75e99d85e0c0bdf83947df5 ]
When the driver disassociate user context, it changes the vma to
anonymous by setting the vm_ops to null and zap the vma ptes.
In order to avoid race in the kernel, we need to take write lock
before we change the vma entries.
Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support')
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/mlx4/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 5a2a0b5db938..9119e0b3c2b8 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1041,7 +1041,7 @@ static void mlx4_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
/* need to protect from a race on closing the vma as part of
* mlx4_ib_vma_close().
*/
- down_read(&owning_mm->mmap_sem);
+ down_write(&owning_mm->mmap_sem);
for (i = 0; i < HW_BAR_COUNT; i++) {
vma = context->hw_bar_info[i].vma;
if (!vma)
@@ -1059,7 +1059,7 @@ static void mlx4_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
context->hw_bar_info[i].vma->vm_ops = NULL;
}
- up_read(&owning_mm->mmap_sem);
+ up_write(&owning_mm->mmap_sem);
mmput(owning_mm);
put_task_struct(owning_process);
}
--
2.14.1
[PATCH AUTOSEL for 4.4 040/101] IB/mlx4: Change vma from shared to private
From: Maor Gottlieb
[ Upstream commit ca37a664a8e4e9988b220988ceb4d79e3316f195 ]
Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise
it would lead to SIGBUS.
Remove the shared flags from the vma after we change it to be
anonymous.
This is easily reproduced by doing modprobe -r while running a
user-space application such as raw_ethernet_bw.
Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support')
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/mlx4/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 9119e0b3c2b8..67c4c73343d4 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1055,6 +1055,8 @@ static void mlx4_ib_disassociate_ucontext(struct
ib_ucontext *ibcontext)
BUG_ON(1);
}
+ context->hw_bar_info[i].vma->vm_flags &=
+ ~(VM_SHARED | VM_MAYSHARE);
/* context going to be destroyed, should not access ops any
more */
context->hw_bar_info[i].vma->vm_ops = NULL;
}
--
2.14.1
Re: [PATCH] thermal: of: Allow selection of thermal governor in DT
On Thu, Mar 8, 2018 at 10:19 AM, Viresh Kumar wrote: > On Wed, Mar 7, 2018 at 4:29 PM, Amit Kucheria > wrote: >> Cpufreq/cpuidle are designed to control a single parameter while >> thermal framework is trying to mitigate heat from several disparate >> sources that are throttled in different ways. Besides, cpufreq/cpuidle >> have somewhat mature governors. Cpuidle has only one governor (for >> tickless) - menu governor, cpufreq has ondemand in mainline, replaced >> by interactive in android and hopefully soon both will be replaced by > > Interactive and schedfreq are already removed from Android 4.4 and 4.9. > It used schedutil now. Good to hear. >> schedutil. >> >> Badly configured cpufreq/cpuidle/devfreq only leads to wasted power, >> while badly configured thermal zone leads to the loss of operation >> e.g. reboots, too hot to touch, etc. > > I don't think such heat-ups will happen right during boot, where some > init.rc should > come up and change the governor. Interestingly enough, there are some patches that make the thermal framework start earlier to deal with boot-time thermal issues. I expect to post them soon. :-) These are required, for example, if the device goes into a reboot loop - the device might not even make it to the point in userspace where the governors are setup. In such a loop, the temperature constantly keeps increasing. > Over that if we are worried about production images only, then what prevents > us > to select the right default governor in the defconfig ? We shouldn't > be worried about > multi-platform kernels for production images. I was refering to the 'make defconfig' out-of-box experience that makes the majority of developer boards/devices out there stable to work on. I can't do that today. Regards, Amit
[PATCH AUTOSEL for 4.4 033/101] tcp: remove poll() flakes with FastOpen
From: Eric Dumazet
[ Upstream commit 0f9fa831aecfc297b7b45d4f046759bcefcf87f0 ]
When using TCP FastOpen for an active session, we send one wakeup event
from tcp_finish_connect(), right before the data eventually contained in
the received SYNACK is queued to sk->sk_receive_queue.
This means that depending on machine load or luck, poll() users
might receive POLLOUT events instead of POLLIN|POLLOUT
To fix this, we need to move the call to sk->sk_state_change()
after the (optional) call to tcp_rcv_fastopen_synack()
Signed-off-by: Eric Dumazet
Acked-by: Yuchung Cheng
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/ipv4/tcp_input.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 71290fb7d500..75433ed6714b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5464,10 +5464,6 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff
*skb)
else
tp->pred_flags = 0;
- if (!sock_flag(sk, SOCK_DEAD)) {
- sk->sk_state_change(sk);
- sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
- }
}
static bool tcp_rcv_fastopen_synack(struct sock *sk, struct sk_buff *synack,
@@ -5531,6 +5527,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk,
struct sk_buff *skb,
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_fastopen_cookie foc = { .len = -1 };
int saved_clamp = tp->rx_opt.mss_clamp;
+ bool fastopen_fail;
tcp_parse_options(skb, &tp->rx_opt, 0, &foc);
if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
@@ -5633,10 +5630,15 @@ static int tcp_rcv_synsent_state_process(struct sock
*sk, struct sk_buff *skb,
tcp_finish_connect(sk, skb);
- if ((tp->syn_fastopen || tp->syn_data) &&
- tcp_rcv_fastopen_synack(sk, skb, &foc))
- return -1;
+ fastopen_fail = (tp->syn_fastopen || tp->syn_data) &&
+ tcp_rcv_fastopen_synack(sk, skb, &foc);
+ if (!sock_flag(sk, SOCK_DEAD)) {
+ sk->sk_state_change(sk);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
+ }
+ if (fastopen_fail)
+ return -1;
if (sk->sk_write_pending ||
icsk->icsk_accept_queue.rskq_defer_accept ||
icsk->icsk_ack.pingpong) {
--
2.14.1
[PATCH AUTOSEL for 4.4 043/101] netfilter: xt_CT: fix refcnt leak on error path
From: Gao Feng
[ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ]
There are two cases which causes refcnt leak.
1. When nf_ct_timeout_ext_add failed in xt_ct_set_timeout, it should
free the timeout refcnt.
Now goto the err_put_timeout error handler instead of going ahead.
2. When the time policy is not found, we should call module_put.
Otherwise, the related cthelper module cannot be removed anymore.
It is easy to reproduce by typing the following command:
# iptables -t raw -A OUTPUT -p tcp -j CT --helper ftp --timeout xxx
Signed-off-by: Gao Feng
Signed-off-by: Liping Zhang
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin
---
net/netfilter/xt_CT.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index e7ac07e53b59..febcfac7e3df 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -168,8 +168,10 @@ xt_ct_set_timeout(struct nf_conn *ct, const struct
xt_tgchk_param *par,
goto err_put_timeout;
}
timeout_ext = nf_ct_timeout_ext_add(ct, timeout, GFP_ATOMIC);
- if (timeout_ext == NULL)
+ if (!timeout_ext) {
ret = -ENOMEM;
+ goto err_put_timeout;
+ }
rcu_read_unlock();
return ret;
@@ -201,6 +203,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
struct xt_ct_target_info_v1 *info)
{
struct nf_conntrack_zone zone;
+ struct nf_conn_help *help;
struct nf_conn *ct;
int ret = -EOPNOTSUPP;
@@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
if (info->timeout[0]) {
ret = xt_ct_set_timeout(ct, par, info->timeout);
if (ret < 0)
- goto err3;
+ goto err4;
}
__set_bit(IPS_CONFIRMED_BIT, &ct->status);
nf_conntrack_get(&ct->ct_general);
@@ -257,6 +260,10 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
info->ct = ct;
return 0;
+err4:
+ help = nfct_help(ct);
+ if (help)
+ module_put(help->helper->me);
err3:
nf_ct_tmpl_free(ct);
err2:
--
2.14.1
[PATCH AUTOSEL for 4.4 045/101] mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()
From: Dan Carpenter
[ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]
devm_pinctrl_get() returns error pointers, it never returns NULL.
Fixes: 455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO
interrupt on AM335x")
Signed-off-by: Dan Carpenter
Reviewed-by: Kishon Vijay Abraham I
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753abe30..6b814d7d6560 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1776,8 +1776,8 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
*/
if (host->pdata->controller_flags & OMAP_HSMMC_SWAKEUP_MISSING) {
struct pinctrl *p = devm_pinctrl_get(host->dev);
- if (!p) {
- ret = -ENODEV;
+ if (IS_ERR(p)) {
+ ret = PTR_ERR(p);
goto err_free_irq;
}
if (IS_ERR(pinctrl_lookup_state(p, PINCTRL_STATE_DEFAULT))) {
--
2.14.1
[PATCH AUTOSEL for 4.4 044/101] openvswitch: Delete conntrack entry clashing with an expectation.
From: Jarno Rajahalme
[ Upstream commit cf5d70918877c6a6655dc1e92e2ebb661ce904fd ]
Conntrack helpers do not check for a potentially clashing conntrack
entry when creating a new expectation. Also, nf_conntrack_in() will
check expectations (via init_conntrack()) only if a conntrack entry
can not be found. The expectation for a packet which also matches an
existing conntrack entry will not be removed by conntrack, and is
currently handled inconsistently by OVS, as OVS expects the
expectation to be removed when the connection tracking entry matching
that expectation is confirmed.
It should be noted that normally an IP stack would not allow reuse of
a 5-tuple of an old (possibly lingering) connection for a new data
connection, so this is somewhat unlikely corner case. However, it is
possible that a misbehaving source could cause conntrack entries be
created that could then interfere with new related connections.
Fix this in the OVS module by deleting the clashing conntrack entry
after an expectation has been matched. This causes the following
nf_conntrack_in() call also find the expectation and remove it when
creating the new conntrack entry, as well as the forthcoming reply
direction packets to match the new related connection instead of the
old clashing conntrack entry.
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Reported-by: Yang Song
Signed-off-by: Jarno Rajahalme
Acked-by: Joe Stringer
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin
---
net/openvswitch/conntrack.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 6a2507f24b0f..1829adb23505 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -361,10 +361,38 @@ ovs_ct_expect_find(struct net *net, const struct
nf_conntrack_zone *zone,
u16 proto, const struct sk_buff *skb)
{
struct nf_conntrack_tuple tuple;
+ struct nf_conntrack_expect *exp;
if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb), proto, net,
&tuple))
return NULL;
- return __nf_ct_expect_find(net, zone, &tuple);
+
+ exp = __nf_ct_expect_find(net, zone, &tuple);
+ if (exp) {
+ struct nf_conntrack_tuple_hash *h;
+
+ /* Delete existing conntrack entry, if it clashes with the
+* expectation. This can happen since conntrack ALGs do not
+* check for clashes between (new) expectations and existing
+* conntrack entries. nf_conntrack_in() will check the
+* expectations only if a conntrack entry can not be found,
+* which can lead to OVS finding the expectation (here) in the
+* init direction, but which will not be removed by the
+* nf_conntrack_in() call, if a matching conntrack entry is
+* found instead. In this case all init direction packets
+* would be reported as new related packets, while reply
+* direction packets would be reported as un-related
+* established packets.
+*/
+ h = nf_conntrack_find_get(net, zone, &tuple);
+ if (h) {
+ struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
+
+ nf_ct_delete(ct, 0, 0);
+ nf_conntrack_put(&ct->ct_general);
+ }
+ }
+
+ return exp;
}
/* Determine whether skb->nfct is equal to the result of conntrack lookup. */
--
2.14.1
[PATCH AUTOSEL for 4.4 047/101] qlcnic: fix unchecked return value
From: Pan Bian [ Upstream commit 91ec701a553cb3de470fd471c6fefe3ad1125455 ] Function pci_find_ext_capability() may return 0, which is an invalid address. In function qlcnic_sriov_virtid_fn(), its return value is used without validation. This may result in invalid memory access bugs. This patch fixes the bug. Signed-off-by: Pan Bian Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c index 7327b729ba2e..ffa6885acfc8 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c @@ -127,6 +127,8 @@ static int qlcnic_sriov_virtid_fn(struct qlcnic_adapter *adapter, int vf_id) return 0; pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_SRIOV); + if (!pos) + return 0; pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, &offset); pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, &stride); -- 2.14.1
linux-next: Tree for Mar 8
Hi all, Changes since 20180307: The sunxi tree gained a build failure so I used the version from next-20180307. The drm tree gained a conflict against the drm-misc-fixes tree. The mfd tree gained a conflict against Linus' tree. The akpm-current tree gained a build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 5684 6129 files changed, 245682 insertions(+), 161271 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 260 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ea9b5ee31078 Merge tag 'gfs2-4.16.rc4.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2) Merging fixes/master (7928b2cbe55b Linux 4.16-rc1) Merging kbuild-current/fixes (638e69cf2230 fixdep: do not ignore kconfig.h) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index) Merging arm64-fixes/for-next/fixes (b08e5fd90bfc arm_pmu: Use disable_irq_nosync when disabling SPI in CPU teardown hook) Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem entry) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (b0c41b8b6e43 powerpc/pseries: Fix vector5 in ibm architecture vector table) Merging sparc/master (aebb48f5e465 sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (b06ef18a4c25 cxgb4: do not set needs_free_netdev for mgmt dev's) Merging bpf/master (20d5de51e705 tools: bpftool: fix compilation with older headers) Merging ipsec/master (87cdf3148b11 xfrm: Verify MAC header exists before overwriting eth_hdr(skb)->h_proto) Merging netfilter/master (0d3601d2994a netfilter: nft_set_hash: skip fixed hash if timeout is specified) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (455f3e76cfc0 brcmfmac: fix P2P_DEVICE ethernet address generation) Merging mac80211/master (a78872363614 cfg80211: add missing dependency to CFG80211 suboptions) Merging rdma-fixes/for-rc (942c9b6ca8de RDMA/bnxt_re: Avoid Hard lockup during error CQE processing) Merging sound-current/for-linus (e312a869cd72 ALSA: hda/realtek - Fix dock line-out volume on Dell Precision 7520) Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when reaching root subordinate) Merging driver-core.current/driver-core-linus (661e50bc8532 Linux 4.16-rc4) Merging tty.current/tty-linus (5d7f77ec72d1 serial: imx: fix bogus dev_err) Merging usb.current/usb-linus (6f566af34628 Revert "typec: tcpm: Only request matching pdos") Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: add binging for r8a77965) Merging usb-serial-fixes/usb-linus (7920a87c40db USB: serial: cp210x: add ELDAT Easywave RX09 id) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fixes (7928b2cbe55b Linux 4.16-rc1) Merging staging.current/staging-linus (740a5759bf22 staging: android: ashmem: Fix possi
[PATCH AUTOSEL for 4.4 042/101] Fix driver usage of 128B WQEs when WQ_CREATE is V1.
From: James Smart
[ Upstream commit 3f247de750b8dd8f50a2c1390e2a1238790a9dff ]
There are two versions of a structure for queue creation and setup that the
driver shares with FW. The driver was only treating as version 0.
Verify WQ_CREATE with 128B WQEs in V0 and V1.
Code review of another bug showed the driver passing
128B WQEs and 8 pages in WQ CREATE and V0.
Code inspection/instrumentation showed that the driver
uses V0 in WQ_CREATE and if the caller passes queue->entry_size
128B, the driver sets the hdr_version to V1 so all is good.
When I tested the V1 WQ_CREATE, the mailbox failed causing
the driver to unload.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
Reviewed-by: Johannes Thumshirn
Signed-off-by: Sasha Levin
---
drivers/scsi/lpfc/lpfc_sli.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 8379fbbc60db..ef43847153ea 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -13493,6 +13493,9 @@ lpfc_wq_create(struct lpfc_hba *phba, struct lpfc_queue
*wq,
case LPFC_Q_CREATE_VERSION_1:
bf_set(lpfc_mbx_wq_create_wqe_count, &wq_create->u.request_1,
wq->entry_count);
+ bf_set(lpfc_mbox_hdr_version, &shdr->request,
+ LPFC_Q_CREATE_VERSION_1);
+
switch (wq->entry_size) {
default:
case 64:
--
2.14.1
[PATCH AUTOSEL for 4.4 048/101] scsi: mac_esp: Replace bogus memory barrier with spinlock
From: Finn Thain
[ Upstream commit 4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]
Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp
chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of
on-board ESP chips (a normal shared IRQ did not work).
Proper mutual exclusion was missing from that patch. This patch fixes
race conditions between comparison and assignment of esp_chips[]
pointers.
Signed-off-by: Finn Thain
Reviewed-by: Michael Schmitz
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/mac_esp.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index 14c0334f41e4..26c67c42985c 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -55,6 +55,7 @@ struct mac_esp_priv {
int error;
};
static struct esp *esp_chips[2];
+static DEFINE_SPINLOCK(esp_chips_lock);
#define MAC_ESP_GET_PRIV(esp) ((struct mac_esp_priv *) \
platform_get_drvdata((struct platform_device *) \
@@ -562,15 +563,18 @@ static int esp_mac_probe(struct platform_device *dev)
}
host->irq = IRQ_MAC_SCSI;
- esp_chips[dev->id] = esp;
- mb();
- if (esp_chips[!dev->id] == NULL) {
- err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
- if (err < 0) {
- esp_chips[dev->id] = NULL;
- goto fail_free_priv;
- }
+
+ /* The request_irq() call is intended to succeed for the first device
+* and fail for the second device.
+*/
+ err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
+ spin_lock(&esp_chips_lock);
+ if (err < 0 && esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
+ goto fail_free_priv;
}
+ esp_chips[dev->id] = esp;
+ spin_unlock(&esp_chips_lock);
err = scsi_esp_register(esp, &dev->dev);
if (err)
@@ -579,8 +583,13 @@ static int esp_mac_probe(struct platform_device *dev)
return 0;
fail_free_irq:
- if (esp_chips[!dev->id] == NULL)
+ spin_lock(&esp_chips_lock);
+ esp_chips[dev->id] = NULL;
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(host->irq, esp);
+ } else
+ spin_unlock(&esp_chips_lock);
fail_free_priv:
kfree(mep);
fail_free_command_block:
@@ -599,9 +608,13 @@ static int esp_mac_remove(struct platform_device *dev)
scsi_esp_unregister(esp);
+ spin_lock(&esp_chips_lock);
esp_chips[dev->id] = NULL;
- if (!(esp_chips[0] || esp_chips[1]))
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(irq, NULL);
+ } else
+ spin_unlock(&esp_chips_lock);
kfree(mep);
--
2.14.1
[PATCH AUTOSEL for 4.4 052/101] mt7601u: check return value of alloc_skb
From: Pan Bian
[ Upstream commit 5fb01e91daf84ad1e50edfcf63116ecbe31e7ba7 ]
Function alloc_skb() will return a NULL pointer if there is no enough
memory. However, in function mt7601u_mcu_msg_alloc(), its return value
is not validated before it is used. This patch fixes it.
Signed-off-by: Pan Bian
Acked-by: Jakub Kicinski
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index fbb1986eda3c..686b1b5dd394 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -66,8 +66,10 @@ mt7601u_mcu_msg_alloc(struct mt7601u_dev *dev, const void
*data, int len)
WARN_ON(len % 4); /* if length is not divisible by 4 we need to pad */
skb = alloc_skb(len + MT_DMA_HDR_LEN + 4, GFP_KERNEL);
- skb_reserve(skb, MT_DMA_HDR_LEN);
- memcpy(skb_put(skb, len), data, len);
+ if (skb) {
+ skb_reserve(skb, MT_DMA_HDR_LEN);
+ memcpy(skb_put(skb, len), data, len);
+ }
return skb;
}
@@ -170,6 +172,8 @@ static int mt7601u_mcu_function_select(struct mt7601u_dev
*dev,
};
skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg));
+ if (!skb)
+ return -ENOMEM;
return mt7601u_mcu_msg_send(dev, skb, CMD_FUN_SET_OP, func == 5);
}
@@ -205,6 +209,8 @@ mt7601u_mcu_calibrate(struct mt7601u_dev *dev, enum
mcu_calibrate cal, u32 val)
};
skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg));
+ if (!skb)
+ return -ENOMEM;
return mt7601u_mcu_msg_send(dev, skb, CMD_CALIBRATION_OP, true);
}
--
2.14.1
[PATCH AUTOSEL for 4.4 050/101] NFS: don't try to cross a mountpount when there isn't one there.
From: NeilBrown
[ Upstream commit 99bbf6ecc694dfe0b026e15359c5aa2a60b97a93 ]
consider the sequence of commands:
mkdir -p /import/nfs /import/bind /import/etc
mount --bind / /import/bind
mount --make-private /import/bind
mount --bind /import/etc /import/bind/etc
exportfs -o rw,no_root_squash,crossmnt,async,no_subtree_check localhost:/
mount -o vers=4 localhost:/ /import/nfs
ls -l /import/nfs/etc
You would not expect this to report a stale file handle.
Yet it does.
The manipulations under /import/bind cause the dentry for
/etc to get the DCACHE_MOUNTED flag set, even though nothing
is mounted on /etc. This causes nfsd to call
nfsd_cross_mnt() even though there is no mountpoint. So an
upcall to mountd for "/etc" is performed.
The 'crossmnt' flag on the export of / causes mountd to
report that /etc is exported as it is a descendant of /. It
assumes the kernel wouldn't ask about something that wasn't
a mountpoint. The filehandle returned identifies the
filesystem and the inode number of /etc.
When this filehandle is presented to rpc.mountd, via
"nfsd.fh", the inode cannot be found associated with any
name in /etc/exports, or with any mountpoint listed by
getmntent(). So rpc.mountd says the filehandle doesn't
exist. Hence ESTALE.
This is fixed by teaching nfsd not to trust DCACHE_MOUNTED
too much. It is just a hint, not a guarantee.
Change nfsd_mountpoint() to return '1' for a certain mountpoint,
'2' for a possible mountpoint, and 0 otherwise.
Then change nfsd_crossmnt() to check if follow_down()
actually found a mountpount and, if not, to avoid performing
a lookup if the location is not known to certainly require
an export-point.
Signed-off-by: NeilBrown
Signed-off-by: J. Bruce Fields
Signed-off-by: Sasha Levin
---
fs/nfsd/vfs.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 91e0c5429b4d..17138a97f306 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -92,6 +92,12 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp,
err = follow_down(&path);
if (err < 0)
goto out;
+ if (path.mnt == exp->ex_path.mnt && path.dentry == dentry &&
+ nfsd_mountpoint(dentry, exp) == 2) {
+ /* This is only a mountpoint in some other namespace */
+ path_put(&path);
+ goto out;
+ }
exp2 = rqst_exp_get_by_name(rqstp, &path);
if (IS_ERR(exp2)) {
@@ -165,16 +171,26 @@ static int nfsd_lookup_parent(struct svc_rqst *rqstp,
struct dentry *dparent, st
/*
* For nfsd purposes, we treat V4ROOT exports as though there was an
* export at *every* directory.
+ * We return:
+ * '1' if this dentry *must* be an export point,
+ * '2' if it might be, if there is really a mount here, and
+ * '0' if there is no chance of an export point here.
*/
int nfsd_mountpoint(struct dentry *dentry, struct svc_export *exp)
{
- if (d_mountpoint(dentry))
+ if (!d_inode(dentry))
+ return 0;
+ if (exp->ex_flags & NFSEXP_V4ROOT)
return 1;
if (nfsd4_is_junction(dentry))
return 1;
- if (!(exp->ex_flags & NFSEXP_V4ROOT))
- return 0;
- return d_inode(dentry) != NULL;
+ if (d_mountpoint(dentry))
+ /*
+* Might only be a mountpoint in a different namespace,
+* but we need to check.
+*/
+ return 2;
+ return 0;
}
__be32
--
2.14.1
[PATCH AUTOSEL for 4.4 054/101] Btrfs: send, fix file hole not being preserved due to inline extent
From: Filipe Manana
[ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ]
Normally we don't have inline extents followed by regular extents, but
there's currently at least one harmless case where this happens. For
example, when the page size is 4Kb and compression is enabled:
$ mkfs.btrfs -f /dev/sdb
$ mount -o compress /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
$ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
In this case we get a compressed inline extent, representing 4Kb of
data, followed by a hole extent and then a regular data extent. The
inline extent was not expanded/converted to a regular extent exactly
because it represents 4Kb of data. This does not cause any apparent
problem (such as the issue solved by commit e1699d2d7bf6
("btrfs: add missing memset while reading compressed inline extents"))
except trigger an unexpected case in the incremental send code path
that makes us issue an operation to write a hole when it's not needed,
resulting in more writes at the receiver and wasting space at the
receiver.
So teach the incremental send code to deal with this particular case.
The issue can be currently triggered by running fstests btrfs/137 with
compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
Signed-off-by: Filipe Manana
Reviewed-by: Liu Bo
Signed-off-by: Sasha Levin
---
fs/btrfs/send.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index c5bbb5300658..19b56873b797 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -5008,13 +5008,19 @@ static int is_extent_unchanged(struct send_ctx *sctx,
while (key.offset < ekey->offset + left_len) {
ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item);
right_type = btrfs_file_extent_type(eb, ei);
- if (right_type != BTRFS_FILE_EXTENT_REG) {
+ if (right_type != BTRFS_FILE_EXTENT_REG &&
+ right_type != BTRFS_FILE_EXTENT_INLINE) {
ret = 0;
goto out;
}
right_disknr = btrfs_file_extent_disk_bytenr(eb, ei);
- right_len = btrfs_file_extent_num_bytes(eb, ei);
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ right_len = btrfs_file_extent_inline_len(eb, slot, ei);
+ right_len = PAGE_ALIGN(right_len);
+ } else {
+ right_len = btrfs_file_extent_num_bytes(eb, ei);
+ }
right_offset = btrfs_file_extent_offset(eb, ei);
right_gen = btrfs_file_extent_generation(eb, ei);
@@ -5028,6 +5034,19 @@ static int is_extent_unchanged(struct send_ctx *sctx,
goto out;
}
+ /*
+* We just wanted to see if when we have an inline extent, what
+* follows it is a regular extent (wanted to check the above
+* condition for inline extents too). This should normally not
+* happen but it's possible for example when we have an inline
+* compressed extent representing data with a size matching
+* the page size (currently the same as sector size).
+*/
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ ret = 0;
+ goto out;
+ }
+
left_offset_fixed = left_offset;
if (key.offset < ekey->offset) {
/* Fix the right offset for 2a and 7. */
--
2.14.1
Re: [PATCH v8 1/5] iommu/arm-smmu: Destroy domain context in failure path
On Wed, Mar 7, 2018 at 5:50 PM, Robin Murphy wrote: > On 02/03/18 10:10, Vivek Gautam wrote: >> >> If we fail after initializing domain_context, we should destroy >> the context to free up resources. > > > Have another think about why the "problem" this patch caters for cannot ever > happen (hint: consider how domain->smmu is used in > arm_smmu_init_domain_context()). And then also about the really > catastrophically bad problem it actually introduces (hint: > "iommu_attach(domain, good_dev); iommu_attach(domain, bad_dev);") Got it, we would end up destroying good_dev's domain context with this. Thanks regards Vivek > > Robin. > > >> Signed-off-by: Vivek Gautam >> --- >> >> * New patch added in this series. >> >> drivers/iommu/arm-smmu.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index 69e7c60792a8..ffc152c36002 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -1223,11 +1223,16 @@ static int arm_smmu_attach_dev(struct iommu_domain >> *domain, struct device *dev) >> dev_err(dev, >> "cannot attach to SMMU %s whilst already attached >> to domain on SMMU %s\n", >> dev_name(smmu_domain->smmu->dev), >> dev_name(smmu->dev)); >> - return -EINVAL; >> + ret = -EINVAL; >> + goto destroy_domain; >> } >> /* Looks ok, so add the device to the domain */ >> return arm_smmu_domain_add_master(smmu_domain, fwspec); >> + >> +destroy_domain: >> + arm_smmu_destroy_domain_context(domain); >> + return ret; >> } >> static int arm_smmu_map(struct iommu_domain *domain, unsigned long >> iova, >> > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH AUTOSEL for 4.4 056/101] mfd: palmas: Reset the POWERHOLD mux during power off
From: Keerthy
[ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
POWERHOLD signal has higher priority over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.
PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold. Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.
Signed-off-by: Keerthy
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/mfd/palmas.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb67a15..a6b5259ffbdd 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,6 +430,20 @@ static void palmas_power_off(void)
{
unsigned int addr;
int ret, slave;
+ struct device_node *np = palmas_dev->dev->of_node;
+
+ if (of_property_read_bool(np, "ti,palmas-override-powerhold")) {
+ addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+ ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+ PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+ if (ret)
+ dev_err(palmas_dev->dev,
+ "Unable to write PRIMARY_SECONDARY_PAD2 %d\n",
+ ret);
+ }
if (!palmas_dev)
return;
--
2.14.1
[PATCH AUTOSEL for 4.4 053/101] rndis_wlan: add return value validation
From: Pan Bian
[ Upstream commit 9dc7efd3978aa67ae598129d2a3f240b390ce508 ]
Function create_singlethread_workqueue() will return a NULL pointer if
there is no enough memory, and its return value should be validated
before using. However, in function rndis_wlan_bind(), its return value
is not checked. This may cause NULL dereference bugs. This patch fixes
it.
Signed-off-by: Pan Bian
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/rndis_wlan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/rndis_wlan.c
b/drivers/net/wireless/rndis_wlan.c
index a13d1f2b5912..259590013382 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -3425,6 +3425,10 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct
usb_interface *intf)
/* because rndis_command() sleeps we need to use workqueue */
priv->workqueue = create_singlethread_workqueue("rndis_wlan");
+ if (!priv->workqueue) {
+ wiphy_free(wiphy);
+ return -ENOMEM;
+ }
INIT_WORK(&priv->work, rndis_wlan_worker);
INIT_DELAYED_WORK(&priv->dev_poller_work, rndis_device_poller);
INIT_DELAYED_WORK(&priv->scan_work, rndis_get_scan_results);
--
2.14.1
[PATCH AUTOSEL for 4.4 058/101] staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y
From: Sameer Wadgaonkar
[ Upstream commit 3c2bf0bd08123f3497bd3e84bd9088c937b0cb40 ]
The root issue is that we are not allowed to have items on the
stack being passed to "DMA" like operations. In this case we have
a vmcall and an inline completion of scsi command.
This patch fixes the issue by moving the variables on stack in
do_scsi_nolinuxstat() to heap memory.
Signed-off-by: Sameer Wadgaonkar
Signed-off-by: David Kershner
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/unisys/visorhba/visorhba_main.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
b/drivers/staging/unisys/visorhba/visorhba_main.c
index c119f20dfd44..3f2ccf9d7358 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -792,7 +792,7 @@ static void
do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)
{
struct scsi_device *scsidev;
- unsigned char buf[36];
+ unsigned char *buf;
struct scatterlist *sg;
unsigned int i;
char *this_page;
@@ -807,6 +807,10 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
scsi_cmnd *scsicmd)
if (cmdrsp->scsi.no_disk_result == 0)
return;
+ buf = kzalloc(sizeof(char) * 36, GFP_KERNEL);
+ if (!buf)
+ return;
+
/* Linux scsi code wants a device at Lun 0
* to issue report luns, but we don't want
* a disk there so we'll present a processor
@@ -820,6 +824,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
scsi_cmnd *scsicmd)
if (scsi_sg_count(scsicmd) == 0) {
memcpy(scsi_sglist(scsicmd), buf,
cmdrsp->scsi.bufflen);
+ kfree(buf);
return;
}
@@ -831,6 +836,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
scsi_cmnd *scsicmd)
memcpy(this_page, buf + bufind, sg[i].length);
kunmap_atomic(this_page_orig);
}
+ kfree(buf);
} else {
devdata = (struct visorhba_devdata *)scsidev->host->hostdata;
for_each_vdisk_match(vdisk, devdata, scsidev) {
--
2.14.1
[PATCH AUTOSEL for 4.4 049/101] infiniband/uverbs: Fix integer overflows
From: Vlad Tsyrklevich
[ Upstream commit 4f7f4dcfff2c19debbcdbcc861c325610a15e0c5 ]
The 'num_sge' variable is verfied to be smaller than the 'sge_count'
variable; however, since both are user-controlled it's possible to cause
an integer overflow for the kmalloc multiply on 32-bit platforms
(num_sge and sge_count are both defined u32). By crafting an input that
causes a smaller-than-expected allocation it's possible to write
controlled data out-of-bounds.
Signed-off-by: Vlad Tsyrklevich
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/uverbs_cmd.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index b7a73f1a8beb..3eb967521917 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2436,9 +2436,13 @@ ssize_t ib_uverbs_destroy_qp(struct ib_uverbs_file *file,
static void *alloc_wr(size_t wr_size, __u32 num_sge)
{
+ if (num_sge >= (U32_MAX - ALIGN(wr_size, sizeof (struct ib_sge))) /
+ sizeof (struct ib_sge))
+ return NULL;
+
return kmalloc(ALIGN(wr_size, sizeof (struct ib_sge)) +
num_sge * sizeof (struct ib_sge), GFP_KERNEL);
-};
+}
ssize_t ib_uverbs_post_send(struct ib_uverbs_file *file,
struct ib_device *ib_dev,
@@ -2665,6 +2669,13 @@ static struct ib_recv_wr
*ib_uverbs_unmarshall_recv(const char __user *buf,
goto err;
}
+ if (user_wr->num_sge >=
+ (U32_MAX - ALIGN(sizeof *next, sizeof (struct ib_sge))) /
+ sizeof (struct ib_sge)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
next = kmalloc(ALIGN(sizeof *next, sizeof (struct ib_sge)) +
user_wr->num_sge * sizeof (struct ib_sge),
GFP_KERNEL);
--
2.14.1
[PATCH AUTOSEL for 4.4 051/101] iio: st_pressure: st_accel: Initialise sensor platform data properly
From: Shrirang Bagul
[ Upstream commit 7383d44b84c94aaca4bf695a6bd8a69f2295ef1a ]
This patch fixes the sensor platform data initialisation for st_pressure
and st_accel device drivers. Without this patch, the driver fails to
register the sensors when the user removes and re-loads the driver.
1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c
$ sudo rmmod st_pressure
2. Re-load the driver
$ sudo insmod st_pressure
$ sudo insmod st_pressure_i2c
Signed-off-by: Jonathan Cameron
Acked-by: Linus Walleij
Signed-off-by: Sasha Levin
---
drivers/iio/accel/st_accel_core.c | 7 ---
drivers/iio/pressure/st_pressure_core.c | 8
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/accel/st_accel_core.c
b/drivers/iio/accel/st_accel_core.c
index 197a08b4e2f3..84ab20c6b389 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -628,6 +628,8 @@ static const struct iio_trigger_ops st_accel_trigger_ops = {
int st_accel_common_probe(struct iio_dev *indio_dev)
{
struct st_sensor_data *adata = iio_priv(indio_dev);
+ struct st_sensors_platform_data *pdata =
+ (struct st_sensors_platform_data *)adata->dev->platform_data;
int irq = adata->get_irq_data_ready(indio_dev);
int err;
@@ -652,9 +654,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
&adata->sensor_settings->fs.fs_avl[0];
adata->odr = adata->sensor_settings->odr.odr_avl[0].hz;
- if (!adata->dev->platform_data)
- adata->dev->platform_data =
- (struct st_sensors_platform_data *)&default_accel_pdata;
+ if (!pdata)
+ pdata = (struct st_sensors_platform_data *)&default_accel_pdata;
err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
if (err < 0)
diff --git a/drivers/iio/pressure/st_pressure_core.c
b/drivers/iio/pressure/st_pressure_core.c
index 5056bd68573f..270eeac928bc 100644
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -436,6 +436,8 @@ static const struct iio_trigger_ops st_press_trigger_ops = {
int st_press_common_probe(struct iio_dev *indio_dev)
{
struct st_sensor_data *press_data = iio_priv(indio_dev);
+ struct st_sensors_platform_data *pdata =
+ (struct st_sensors_platform_data
*)press_data->dev->platform_data;
int irq = press_data->get_irq_data_ready(indio_dev);
int err;
@@ -464,10 +466,8 @@ int st_press_common_probe(struct iio_dev *indio_dev)
press_data->odr = press_data->sensor_settings->odr.odr_avl[0].hz;
/* Some devices don't support a data ready pin. */
- if (!press_data->dev->platform_data &&
- press_data->sensor_settings->drdy_irq.addr)
- press_data->dev->platform_data =
- (struct st_sensors_platform_data *)&default_press_pdata;
+ if (!pdata && press_data->sensor_settings->drdy_irq.addr)
+ pdata = (struct st_sensors_platform_data *)&default_press_pdata;
err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
if (err < 0)
--
2.14.1
[PATCH AUTOSEL for 4.4 055/101] mac80211: don't parse encrypted management frames in ieee80211_frame_acked
From: Emmanuel Grumbach
[ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ]
ieee80211_frame_acked is called when a frame is acked by
the peer. In case this is a management frame, we check
if this an SMPS frame, in which case we can update our
antenna configuration.
When we parse the management frame we look at the category
in case it is an action frame. That byte sits after the IV
in case the frame was encrypted. This means that if the
frame was encrypted, we basically look at the IV instead
of looking at the category. It is then theorically
possible that we think that an SMPS action frame was acked
where really we had another frame that was encrypted.
Since the only management frame whose ack needs to be
tracked is the SMPS action frame, and that frame is not
a robust management frame, it will never be encrypted.
The easiest way to fix this problem is then to not look
at frames that were encrypted.
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
---
net/mac80211/status.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 5bad05e9af90..45fb1abdb265 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -194,6 +194,7 @@ static void ieee80211_frame_acked(struct sta_info *sta,
struct sk_buff *skb)
}
if (ieee80211_is_action(mgmt->frame_control) &&
+ !ieee80211_has_protected(mgmt->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_HT &&
mgmt->u.action.u.ht_smps.action == WLAN_HT_ACTION_SMPS &&
ieee80211_sdata_running(sdata)) {
--
2.14.1
RE: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()
> > +({ \
> > + struct efi_runtime_work efi_rts_work; \
> > + \
> > + INIT_WORK_ONSTACK(&efi_rts_work.work, efi_call_rts);\
> > + efi_rts_work.func = _rts; \
> > + efi_rts_work.arg1 = _arg1; \
> > + efi_rts_work.arg2 = _arg2; \
> > + efi_rts_work.arg3 = _arg3; \
> > + efi_rts_work.arg4 = _arg4; \
> > + efi_rts_work.arg5 = _arg5; \
> > + /* \
> > +* queue_work() returns 0 if work was already on queue, \
> > +* _ideally_ this should never happen. \
> > +*/ \
> > + if (queue_work(efi_rts_wq, &efi_rts_work.work))
> \
> > + flush_work(&efi_rts_work.work);
> \
> > + else\
> > + BUG(); \
>
> So failure to queue that work is such a critical problem that we need to BUG()
> and can't possibly continue and shoult not attempt recovery at all?
>
I think it's not critical, we can just return error status.
I think the problem in itself is not at all critical but when I initially
thought about
why the problem could have occurred, it sounded like one i.e. ideally (if the
system
is running fine) we should always be able to queue work. Failure to queue means
that the previous work is already on queue and that shouldn't be the case.
So, thought, maybe something bad had happened already (just doubtful).
But, I see your point. BUG() sounds more like an over kill. Instead of fixing
an existing
problem, this patch could completely take down the system.
> IOW, we should always strive to fail gracefully and not shit in pants at the
> first
> sign of trouble.
>
Yes, that makes sense. I will remove BUG() in V3 (in the two places that I
introduced).
> Even checkpatch warns here:
>
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> rather than BUG() or BUG_ON()
> #184: FILE: drivers/firmware/efi/runtime-wrappers.c:92:
> + BUG(); \
>
Sure! I will fix this
>
> and by looking at the other output, you should run your patches through
> checkpatch. Some of the things make sense like:
>
> WARNING: quoted string split across lines
> #97: FILE: drivers/firmware/efi/efi.c:341:
> + pr_err("Failed to create efi_rts_workqueue, EFI runtime
> services "
> + "disabled.\n");
>
> for example.
>
I will fix this one too.
Another warning by checkpatch is "use of in_atomic() in drivers code"
Do you think it's OK to check if were are "in_atomic()" in drivers code.
I wasn't able to decide on other alternative, if possible, could you please
suggest one?
Regards,
Sai
[PATCH AUTOSEL for 4.4 060/101] mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a
From: yangbo lu
[ Upstream commit a627f025eb0534052ff451427c16750b3530634c ]
The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.
Signed-off-by: Yangbo Lu
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
---
drivers/mmc/host/sdhci-of-esdhc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 83b1226471c1..ac66c61d9433 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -418,6 +418,20 @@ static void esdhc_of_set_clock(struct sdhci_host *host,
unsigned int clock)
if (esdhc->vendor_ver < VENDOR_V_23)
pre_div = 2;
+ /*
+* Limit SD clock to 167MHz for ls1046a according to its datasheet
+*/
+ if (clock > 16700 &&
+ of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc"))
+ clock = 16700;
+
+ /*
+* Limit SD clock to 125MHz for ls1012a according to its datasheet
+*/
+ if (clock > 12500 &&
+ of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc"))
+ clock = 12500;
+
/* Workaround to reduce the clock frequency for p1010 esdhc */
if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) {
if (clock > 2000)
--
2.14.1
[PATCH AUTOSEL for 4.4 064/101] drm/nouveau/kms: Increase max retries in scanout position queries.
From: Mario Kleiner
[ Upstream commit 60b95d709525e3ce1c51e1fc93175dcd1755d345 ]
So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.
Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank stuff, e.g.,
desktop compositors.
Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.
As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.
Signed-off-by: Mario Kleiner
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 00de1bf81519..9dfc2471ea09 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -104,7 +104,7 @@ nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int
*vpos, int *hpos,
};
struct nouveau_display *disp = nouveau_display(crtc->dev);
struct drm_vblank_crtc *vblank =
&crtc->dev->vblank[drm_crtc_index(crtc)];
- int ret, retry = 1;
+ int ret, retry = 20;
do {
ret = nvif_mthd(&disp->disp, 0, &args, sizeof(args));
--
2.14.1
[PATCH AUTOSEL for 4.4 065/101] bnx2x: Align RX buffers
From: Scott Wood [ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ] The bnx2x driver is not providing proper alignment on the receive buffers it passes to build_skb(), causing skb_shared_info to be misaligned. skb_shared_info contains an atomic, and while PPC normally supports unaligned accesses, it does not support unaligned atomics. Aligning the size of rx buffers will ensure that page_frag_alloc() returns aligned addresses. This can be reproduced on PPC by setting the network MTU to 1450 (or other non-multiple-of-4) and then generating sufficient inbound network traffic (one or two large "wget"s usually does it), producing the following oops: Unable to handle kernel paging request for unaligned access at address 0xc0ffc43af656 Faulting instruction address: 0xc080ef8c Oops: Kernel access of bad area, sig: 7 [#1] SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2 task: c0ffd4892400 task.stack: c0ffd492 NIP: c080ef8c LR: c080eee8 CTR: c01f8320 REGS: c0c33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da) MSR: 90009033 CR: 24082042 XER: CFAR: c080eea0 DAR: c0ffc43af656 DSISR: SOFTE: 1 GPR00: c0907f64 c0c33990 c0dd3b00 c0ffcaf22100 GPR04: c0ffcaf22e00 GPR08: 00b80008 c0ffc43af636 c0ffc43af656 GPR12: c01f6f00 cfe1a000 049f c51f GPR16: ef33 8a43 0001 GPR20: c0ffc58a90c0 dd86 GPR24: c07fd0ed10c0 0158 014a GPR28: c0ffc43af010 c0ffc9144000 c0ffcaf22e00 c0ffcaf22100 NIP [c080ef8c] __skb_clone+0xdc/0x140 LR [c080eee8] __skb_clone+0x38/0x140 Call Trace: [c0c33990] [c080fb74] skb_clone+0x74/0x110 (unreliable) [c0c339c0] [c0907f64] packet_rcv+0x144/0x510 [c0c33a40] [c0827b64] __netif_receive_skb_core+0x5b4/0xd80 [c0c33b00] [c082b2bc] netif_receive_skb_internal+0x2c/0xc0 [c0c33b40] [c082c49c] napi_gro_receive+0x11c/0x260 [c0c33b80] [d00066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x] [c0c33d00] [c082babc] net_rx_action+0x31c/0x480 [c0c33e10] [c00d5a44] __do_softirq+0x164/0x3d0 [c0c33f00] [c00d60a8] irq_exit+0x108/0x120 [c0c33f20] [c0015b98] __do_irq+0x98/0x200 [c0c33f90] [c0027f14] call_do_irq+0x14/0x24 [c0ffd4923a90] [c0015d94] do_IRQ+0x94/0x110 [c0ffd4923ae0] [c0008d90] hardware_interrupt_common+0x150/0x160 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c index e5911ccb2148..889462170b7c 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c @@ -2044,6 +2044,7 @@ static void bnx2x_set_rx_buf_size(struct bnx2x *bp) ETH_OVREHEAD + mtu + BNX2X_FW_RX_ALIGN_END; + fp->rx_buf_size = SKB_DATA_ALIGN(fp->rx_buf_size); /* Note : rx_buf_size doesn't take into account NET_SKB_PAD */ if (fp->rx_buf_size + NET_SKB_PAD <= PAGE_SIZE) fp->rx_frag_size = fp->rx_buf_size + NET_SKB_PAD; -- 2.14.1
[PATCH AUTOSEL for 4.4 063/101] ACPI / PMIC: xpower: Fix power_table addresses
From: Hans de Goede
[ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ]
The power table addresses should be contiguous, but there was a hole
where 0x34 was missing. On most devices this is not a problem as
addresses above 0x34 are used for the BUC# convertors which are not
used in the DSDTs I've access to but after the BUC# convertors
there is a field named GPI1 in the DSTDs, which does get used in some
cases and ended up turning BUC6 on and off due to the wrong addresses,
resulting in turning the entire device off (or causing it to reboot).
Removing the hole in the addresses fixes this, fixing one of my
Bay Trail tablets turning off while booting the mainline kernel.
While at it add comments with the field names used in the DSDTs to
make it easier to compare the register and bits used at each address
with the datasheet.
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
---
drivers/acpi/pmic/intel_pmic_xpower.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c
b/drivers/acpi/pmic/intel_pmic_xpower.c
index 6a082d4de12c..24a793957bc0 100644
--- a/drivers/acpi/pmic/intel_pmic_xpower.c
+++ b/drivers/acpi/pmic/intel_pmic_xpower.c
@@ -28,97 +28,97 @@ static struct pmic_table power_table[] = {
.address = 0x00,
.reg = 0x13,
.bit = 0x05,
- },
+ }, /* ALD1 */
{
.address = 0x04,
.reg = 0x13,
.bit = 0x06,
- },
+ }, /* ALD2 */
{
.address = 0x08,
.reg = 0x13,
.bit = 0x07,
- },
+ }, /* ALD3 */
{
.address = 0x0c,
.reg = 0x12,
.bit = 0x03,
- },
+ }, /* DLD1 */
{
.address = 0x10,
.reg = 0x12,
.bit = 0x04,
- },
+ }, /* DLD2 */
{
.address = 0x14,
.reg = 0x12,
.bit = 0x05,
- },
+ }, /* DLD3 */
{
.address = 0x18,
.reg = 0x12,
.bit = 0x06,
- },
+ }, /* DLD4 */
{
.address = 0x1c,
.reg = 0x12,
.bit = 0x00,
- },
+ }, /* ELD1 */
{
.address = 0x20,
.reg = 0x12,
.bit = 0x01,
- },
+ }, /* ELD2 */
{
.address = 0x24,
.reg = 0x12,
.bit = 0x02,
- },
+ }, /* ELD3 */
{
.address = 0x28,
.reg = 0x13,
.bit = 0x02,
- },
+ }, /* FLD1 */
{
.address = 0x2c,
.reg = 0x13,
.bit = 0x03,
- },
+ }, /* FLD2 */
{
.address = 0x30,
.reg = 0x13,
.bit = 0x04,
- },
+ }, /* FLD3 */
{
- .address = 0x38,
+ .address = 0x34,
.reg = 0x10,
.bit = 0x03,
- },
+ }, /* BUC1 */
{
- .address = 0x3c,
+ .address = 0x38,
.reg = 0x10,
.bit = 0x06,
- },
+ }, /* BUC2 */
{
- .address = 0x40,
+ .address = 0x3c,
.reg = 0x10,
.bit = 0x05,
- },
+ }, /* BUC3 */
{
- .address = 0x44,
+ .address = 0x40,
.reg = 0x10,
.bit = 0x04,
- },
+ }, /* BUC4 */
{
- .address = 0x48,
+ .address = 0x44,
.reg = 0x10,
.bit = 0x01,
- },
+ }, /* BUC5 */
{
- .address = 0x4c,
+ .address = 0x48,
.reg = 0x10,
.bit = 0x00
- },
+ }, /* BUC6 */
};
/* TMP0 - TMP5 are the same, all from GPADC */
--
2.14.1
[PATCH AUTOSEL for 4.4 067/101] Input: twl4030-pwrbutton - use correct device for irq request
From: Sebastian Reichel
[ Upstream commit 3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 ]
The interrupt should be requested for the platform device
and not for the input device.
Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
Signed-off-by: Sebastian Reichel
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin
---
drivers/input/misc/twl4030-pwrbutton.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index 603fc2fadf05..12b20840fb74 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -70,7 +70,7 @@ static int twl4030_pwrbutton_probe(struct platform_device
*pdev)
pwr->phys = "twl4030_pwrbutton/input0";
pwr->dev.parent = &pdev->dev;
- err = devm_request_threaded_irq(&pwr->dev, irq, NULL, powerbutton_irq,
+ err = devm_request_threaded_irq(&pdev->dev, irq, NULL, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
"twl4030_pwrbutton", pwr);
--
2.14.1
RE: [PATCH V2 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services
> >> > pstore writes could potentially be invoked in interrupt context and
> >> > it uses set_variable<>() and query_variable_info<>() to store logs.
> >> > If we invoke efi_runtime_services() through efi_rts_wq while in
> >> > atomic() kernel issues a warning ("scheduling wile in atomic") and
> >> > prints stack trace. One way to overcome this is to not make the
> >> > caller process wait for the worker thread to finish. This approach
> >> > breaks pstore i.e. the log messages aren't written to efi
> >> > variables. Hence, pstore calls
> >> > efi_runtime_services() without using efi_rts_wq or in other words
> >> > efi_rts_wq will be used unconditionally for all the
> >> > efi_runtime_services() except set_variable<>() and
> >> > query_variable_info<>()
> >>
> >> Can't NMIs still come in during this?
> >>
> >> ... or do we assume that since something has already gone wrong, this
> >> doesn't matter?
> >>
> >
> > I think they can come. AFAIK, pstore (if enabled) runs only when we crashed.
> > Since, we are still executing stuff to log messages and NMI's can't be
> > masked, there is still a possibility for NMI's to occur (please correct me
> > if I am
> wrong).
> > But, as you said earlier, I guess it doesn't matter because anyways we are
> going down.
>
> The problem is that we are not always in a "already going down"
> condition for typical set_variable and query_variable_info calls.
That's correct.
> So are we actually fixing anything with this patchset?
When we are _not_ in interrupt context (eg: process context)
we still use efi_rts_wq to invoke *all* efi_runtime_services().
This solves *someone trying to access user space* while in EFI runtime services
mapping problem. A instance could be, some user space process requests us to
execute efi_runtime_service(), so, kernel switches to efi_pgd (which doesn’t
have
user space part of process address space) and while executing
efi_runtime_service()
perf NMI comes along to profile user data.
> In other words if the NMI vs EFI
> mapping problem requires the workqueue context then we can't have any EFI
> calls outside of that context. Am I missing how this scheme addresses that
> problem?
I think so, because, we are not trying to solve NMI vs EFI Runtime Service
mappings.
AFAIK, they both work together (for x86_64). The problem is, as stated above,
"someone trying to access user space while executing EFI runtime services".
The problem exists because EFI runtime services mappings don’t have user space
part of process address space.
I think the problem still persists when we are already in interrupt context and
then
we were requested to execute some efi_runtime_service() and then NMI happens
and that NMI handler touches user space.
Please let me know if my explanation didn’t make sense or if I misunderstood
your question.
Ard and Matt, please correct me if I stated something that is incorrect.
[PATCH AUTOSEL for 4.4 066/101] power: supply: pda_power: move from timer to delayed_work
From: Michael Trimarchi
[ Upstream commit 633e8799ddc09431be2744c4a1efdbda13af2b0b ]
This changed is needed to avoid locking problem during
boot as shown:
<5>[8.824096] Registering SWP/SWPB emulation handler
<6>[8.977294] clock: disabling unused clocks to save power
<3>[9.108154] BUG: sleeping function called from invalid context at
kernel_albert/kernel/mutex.c:269
<3>[9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
<4>[9.130249] 3 locks held by swapper/0/1:
<4>[9.134613] #0: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x58/0xa8
<4>[9.144500] #1: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x68/0xa8
<4>[9.154357] #2: (&polling_timer){..}, at: []
run_timer_softirq+0x108/0x3ec
<4>[9.163726] Backtrace:
<4>[9.166473] [] (dump_backtrace+0x0/0x114) from []
(dump_stack+0x20/0x24)
<4>[9.175811] r6:00203230 r5:010d r4:d782e000 r3:6113
<4>[9.182250] [] (dump_stack+0x0/0x24) from []
(__might_sleep+0x10c/0x128)
<4>[9.191650] [] (__might_sleep+0x0/0x128) from []
(mutex_lock_nested+0x34/0x36c)
<4>[9.201660] r5:c02d5350 r4:d79a0c64
<4>[9.205688] [] (mutex_lock_nested+0x0/0x36c) from []
(regulator_set_current_limit+0x30/0x118)
<4>[9.217071] [] (regulator_set_current_limit+0x0/0x118) from
[] (update_charger+0x84/0xc4)
<4>[9.228027] r7:d782fb20 r6:0101 r5:c1767e94 r4:
<4>[9.234436] [] (update_charger+0x0/0xc4) from []
(psy_changed+0x20/0x48)
<4>[9.243804] r5:d782e000 r4:c1767e94
<4>[9.247802] [] (psy_changed+0x0/0x48) from []
(polling_timer_func+0x84/0xb8)
<4>[9.257537] r4:c1767e94 r3:0002
<4>[9.261566] [] (polling_timer_func+0x0/0xb8) from []
(run_timer_softirq+0x17c/0x3ec)
<4>[9.272033] r4:c1767eb0 r3:
<4>[9.276062] [] (run_timer_softirq+0x0/0x3ec) from []
(__do_softirq+0xf0/0x298)
<4>[9.286010] [] (__do_softirq+0x0/0x298) from []
(irq_exit+0x98/0xa0)
<4>[9.295013] [] (irq_exit+0x0/0xa0) from []
(handle_IRQ+0x60/0xc0)
<4>[9.303680] r4:c1194e98 r3:c00bc778
<4>[9.307708] [] (handle_IRQ+0x0/0xc0) from []
(gic_handle_irq+0x34/0x68)
<4>[9.316955] r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
<4>[9.324310] r3:c026ba48
<4>[9.327301] [] (gic_handle_irq+0x0/0x68) from []
(__irq_svc+0x40/0x74)
<4>[9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
<4>[9.342041] fc00: d6e30e6c ac383627 ac383417
ea19c000 ea20
<4>[9.351104] fc20: beff 0667 000ac383 d6e30670 d6e3066c d782fc94
d782fbe8 d782fc50
<4>[9.360168] fc40: c026ba48 c001d1f0 0113
Fixes: b2998049cfae ("[BATTERY] pda_power platform driver")
Signed-off-by: Michael Trimarchi
Signed-off-by: Anthony Brandon
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
---
drivers/power/pda_power.c | 49 ++-
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index dfe1ee89f7c7..922a86787c5c 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -30,9 +30,9 @@ static inline unsigned int get_irq_flags(struct resource *res)
static struct device *dev;
static struct pda_power_pdata *pdata;
static struct resource *ac_irq, *usb_irq;
-static struct timer_list charger_timer;
-static struct timer_list supply_timer;
-static struct timer_list polling_timer;
+static struct delayed_work charger_work;
+static struct delayed_work polling_work;
+static struct delayed_work supply_work;
static int polling;
static struct power_supply *pda_psy_ac, *pda_psy_usb;
@@ -140,7 +140,7 @@ static void update_charger(void)
}
}
-static void supply_timer_func(unsigned long unused)
+static void supply_work_func(struct work_struct *work)
{
if (ac_status == PDA_PSY_TO_CHANGE) {
ac_status = new_ac_status;
@@ -161,11 +161,12 @@ static void psy_changed(void)
* Okay, charger set. Now wait a bit before notifying supplicants,
* charge power should stabilize.
*/
- mod_timer(&supply_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_charger));
+ cancel_delayed_work(&supply_work);
+ schedule_delayed_work(&supply_work,
+ msecs_to_jiffies(pdata->wait_for_charger));
}
-static void charger_timer_func(unsigned long unused)
+static void charger_work_func(struct work_struct *work)
{
update_status();
psy_changed();
@@ -184,13 +185,14 @@ static irqreturn_t power_changed_isr(int irq, void
*power_supply)
* Wait a bit before reading ac/usb line status and setting charger,
* because ac/usb status readings may lag from irq.
*/
- mod_timer(&charger_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_status));
+ cancel_delayed_work(&charger_work);
+ schedule_delayed_work(&charge
[PATCH AUTOSEL for 4.4 062/101] ipmi/watchdog: fix wdog hang on panic waiting for ipmi response
From: Robert Lippert
[ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]
Commit c49c097610fe ("ipmi: Don't call receive handler in the
panic context") means that the panic_recv_free is not called during a
panic and the atomic count does not drop to 0.
Fix this by only expecting one decrement of the atomic variable
which comes from panic_smi_free.
Signed-off-by: Robert Lippert
Signed-off-by: Corey Minyard
Signed-off-by: Sasha Levin
---
drivers/char/ipmi/ipmi_watchdog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index 40d400fe5bb7..4ada103945f0 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -515,7 +515,7 @@ static void panic_halt_ipmi_heartbeat(void)
msg.cmd = IPMI_WDOG_RESET_TIMER;
msg.data = NULL;
msg.data_len = 0;
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = ipmi_request_supply_msgs(watchdog_user,
(struct ipmi_addr *) &addr,
0,
@@ -525,7 +525,7 @@ static void panic_halt_ipmi_heartbeat(void)
&panic_halt_heartbeat_recv_msg,
1);
if (rv)
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
}
static struct ipmi_smi_msg panic_halt_smi_msg = {
@@ -549,12 +549,12 @@ static void panic_halt_ipmi_set_timeout(void)
/* Wait for the messages to be free. */
while (atomic_read(&panic_done_count) != 0)
ipmi_poll_interface(watchdog_user);
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = i_ipmi_set_timeout(&panic_halt_smi_msg,
&panic_halt_recv_msg,
&send_heartbeat_now);
if (rv) {
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
printk(KERN_WARNING PFX
"Unable to extend the watchdog timeout.");
} else {
--
2.14.1
[PATCH AUTOSEL for 4.4 071/101] video: fbdev: udlfb: Fix buffer on stack
From: Maksim Salau
[ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]
Allocate buffers on HEAP instead of STACK for local array
that is to be sent using usb_control_msg().
Signed-off-by: Maksim Salau
Cc: Bernie Thompson
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/udlfb.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 53326badfb61..2add8def83be 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1487,15 +1487,25 @@ static struct device_attribute fb_device_attrs[] = {
static int dlfb_select_std_channel(struct dlfb_data *dev)
{
int ret;
- u8 set_def_chn[] = { 0x57, 0xCD, 0xDC, 0xA7,
+ void *buf;
+ static const u8 set_def_chn[] = {
+ 0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
0x60, 0xFE, 0xC6, 0x97,
0x16, 0x3D, 0x47, 0xF2 };
+ buf = kmemdup(set_def_chn, sizeof(set_def_chn), GFP_KERNEL);
+
+ if (!buf)
+ return -ENOMEM;
+
ret = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
NR_USB_REQUEST_CHANNEL,
(USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
- set_def_chn, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+ buf, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+
+ kfree(buf);
+
return ret;
}
--
2.14.1
[PATCH AUTOSEL for 4.4 061/101] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
From: Kishon Vijay Abraham I
[ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]
The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be
set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC
mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
Acked-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Bjorn Helgaas
Signed-off-by: Sasha Levin
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 7581e036bda6..70e3b711e79c 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm = {
.dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs = pcie_wkup_sleep_deps,
.sleepdep_srcs= pcie_wkup_sleep_deps,
- .flags= CLKDM_CAN_HWSUP_SWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain atl_7xx_clkdm = {
--
2.14.1
[PATCH AUTOSEL for 4.4 070/101] tcm_fileio: Prevent information leak for short reads
From: Dmitry Monakhov
[ Upstream commit f11b55d13563e9428c88c873f4f03a6bef11ec0a ]
If we failed to read data from backing file (probably because some one
truncate file under us), we must zerofill cmd's data, otherwise it will
be returned as is. Most likely cmd's data are unitialized pages from
page cache. This result in information leak.
(Change BUG_ON into -EINVAL se_cmd failure - nab)
testcase:
https://github.com/dmonakhov/xfstests/commit/e11a1b7b907ca67b1be51a1594025600767366d5
Signed-off-by: Dmitry Monakhov
Signed-off-by: Nicholas Bellinger
Signed-off-by: Sasha Levin
---
drivers/target/target_core_file.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
index 2e35db7f4aac..c15af2fcf2ba 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -276,12 +276,11 @@ static int fd_do_rw(struct se_cmd *cmd, struct file *fd,
else
ret = vfs_iter_read(fd, &iter, &pos);
- kfree(bvec);
-
if (is_write) {
if (ret < 0 || ret != data_length) {
pr_err("%s() write returned %d\n", __func__, ret);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
/*
@@ -294,17 +293,29 @@ static int fd_do_rw(struct se_cmd *cmd, struct file *fd,
pr_err("%s() returned %d, expecting %u for "
"S_ISBLK\n", __func__, ret,
data_length);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
if (ret < 0) {
pr_err("%s() returned %d for non S_ISBLK\n",
__func__, ret);
- return ret;
+ } else if (ret != data_length) {
+ /*
+* Short read case:
+* Probably some one truncate file under us.
+* We must explicitly zero sg-pages to prevent
+* expose uninizialized pages to userspace.
+*/
+ if (ret < data_length)
+ ret += iov_iter_zero(data_length - ret,
&iter);
+ else
+ ret = -EINVAL;
}
}
}
- return 1;
+ kfree(bvec);
+ return ret;
}
static sense_reason_t
--
2.14.1
[PATCH AUTOSEL for 4.4 069/101] ia64: fix module loading for gcc-5.4
From: Sergei Trofimovich
[ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ]
Starting from gcc-5.4+ gcc generates MLX instructions in more cases to
refer local symbols:
https://gcc.gnu.org/PR60465
That caused ia64 module loader to choke on such instructions:
fuse: invalid slot number 1 for IMM64
The Linux kernel used to handle only case where relocation pointed to
slot=2 instruction in the bundle. That limitation was fixed in linux by
commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler")
See
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433
This change lifts the slot=2 restriction from the kernel module loader.
Tested on 'fuse' and 'btrfs' kernel modules.
Cc: Markus Elfring
Cc: H J Lu
Cc: Fenghua Yu
Cc: Andrew Morton
Bug: https://bugs.gentoo.org/601014
Tested-by: Émeric MASCHINO
Signed-off-by: Sergei Trofimovich
Signed-off-by: Tony Luck
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/ia64/kernel/module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/module.c b/arch/ia64/kernel/module.c
index b15933c31b2f..36b2c94a8eb5 100644
--- a/arch/ia64/kernel/module.c
+++ b/arch/ia64/kernel/module.c
@@ -153,7 +153,7 @@ slot (const struct insn *insn)
static int
apply_imm64 (struct module *mod, struct insn *insn, uint64_t val)
{
- if (slot(insn) != 2) {
+ if (slot(insn) != 1 && slot(insn) != 2) {
printk(KERN_ERR "%s: invalid slot number %d for IMM64\n",
mod->name, slot(insn));
return 0;
@@ -165,7 +165,7 @@ apply_imm64 (struct module *mod, struct insn *insn,
uint64_t val)
static int
apply_imm60 (struct module *mod, struct insn *insn, uint64_t val)
{
- if (slot(insn) != 2) {
+ if (slot(insn) != 1 && slot(insn) != 2) {
printk(KERN_ERR "%s: invalid slot number %d for IMM60\n",
mod->name, slot(insn));
return 0;
--
2.14.1
[PATCH AUTOSEL for 4.4 072/101] sm501fb: don't return zero on failure path in sm501fb_start()
From: Alexey Khoroshilov
[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Cc: Tomi Valkeinen
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/sm501fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index d0a4e2f79a57..d215faacce04 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1600,6 +1600,7 @@ static int sm501fb_start(struct sm501fb_info *info,
info->fbmem = ioremap(res->start, resource_size(res));
if (info->fbmem == NULL) {
dev_err(dev, "cannot remap framebuffer\n");
+ ret = -ENXIO;
goto err_mem_res;
}
--
2.14.1
[PATCH AUTOSEL for 4.4 074/101] cifs: small underflow in cnvrtDosUnixTm()
From: Dan Carpenter
[ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ]
January is month 1. There is no zero-th month. If someone passes a
zero month then it means we read from one space before the start of the
total_days_of_prev_months[] array.
We may as well also be strict about days as well.
Fixes: 1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
Signed-off-by: Dan Carpenter
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/netmisc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
index abae6dd2c6b9..cc88f4f0325e 100644
--- a/fs/cifs/netmisc.c
+++ b/fs/cifs/netmisc.c
@@ -980,10 +980,10 @@ struct timespec cnvrtDosUnixTm(__le16 le_date, __le16
le_time, int offset)
cifs_dbg(VFS, "illegal hours %d\n", st->Hours);
days = sd->Day;
month = sd->Month;
- if ((days > 31) || (month > 12)) {
+ if (days < 1 || days > 31 || month < 1 || month > 12) {
cifs_dbg(VFS, "illegal date, month %d day: %d\n", month, days);
- if (month > 12)
- month = 12;
+ days = clamp(days, 1, 31);
+ month = clamp(month, 1, 12);
}
month -= 1;
days += total_days_of_prev_months[month];
--
2.14.1
[PATCH AUTOSEL for 4.4 068/101] md/raid10: skip spare disk as 'first' disk
From: Shaohua Li [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ] Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores a case in reshape, the first rdev could be a spare disk, which shouldn't be accounted as the first disk since it doesn't include the offset info. Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop) Cc: Guoqing Jiang Cc: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin --- drivers/md/raid10.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index 05548af8df6f..3a0d557146c7 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -4044,6 +4044,7 @@ static int raid10_start_reshape(struct mddev *mddev) diff = 0; if (first || diff < min_offset_diff) min_offset_diff = diff; + first = 0; } } -- 2.14.1
[PATCH AUTOSEL for 4.4 075/101] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
From: Moritz Fischer
[ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.
Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer
Signed-off-by: Alexandre Belloni
Signed-off-by: Sasha Levin
---
drivers/rtc/rtc-ds1374.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 3b3049c8c9e0..5b5bc7dc3a1c 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -527,6 +527,10 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned
int cmd,
if (get_user(new_margin, (int __user *)arg))
return -EFAULT;
+ /* the hardware's tick rate is 4096 Hz, so
+* the counter value needs to be scaled accordingly
+*/
+ new_margin <<= 12;
if (new_margin < 1 || new_margin > 16777216)
return -EINVAL;
@@ -535,7 +539,8 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned
int cmd,
ds1374_wdt_ping();
/* fallthrough */
case WDIOC_GETTIMEOUT:
- return put_user(wdt_margin, (int __user *)arg);
+ /* when returning ... inverse is true */
+ return put_user((wdt_margin >> 12), (int __user *)arg);
case WDIOC_SETOPTIONS:
if (copy_from_user(&options, (int __user *)arg, sizeof(int)))
return -EFAULT;
--
2.14.1
[PATCH AUTOSEL for 4.4 076/101] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
From: Moritz Fischer
[ Upstream commit 538c08f4c89580fc644e2bc64e0a4b86c925da4e ]
The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.
Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer
Signed-off-by: Alexandre Belloni
Signed-off-by: Sasha Levin
---
drivers/rtc/rtc-ds1374.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 5b5bc7dc3a1c..c0eb113588ff 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -548,14 +548,15 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned
int cmd,
if (options & WDIOS_DISABLECARD) {
pr_info("disable watchdog\n");
ds1374_wdt_disable();
+ return 0;
}
if (options & WDIOS_ENABLECARD) {
pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
+ return 0;
}
-
return -EINVAL;
}
return -ENOTTY;
--
2.14.1
[PATCH AUTOSEL for 4.4 078/101] Bluetooth: hci_qca: Avoid setup failure on missing rampatch
From: Loic Poulain
[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]
Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.
This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x0008
hci0: Patch :0x0111
hci0: ROM:0x0302
hci0: SOC:0x0044
Since there is no rampatch for this controller revision, just make
it work as is.
Signed-off-by: Loic Poulain
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 71325e443e46..8a3bf0a8c31d 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -936,6 +936,9 @@ static int qca_setup(struct hci_uart *hu)
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
qca_debugfs_init(hdev);
+ } else if (ret == -ENOENT) {
+ /* No patch/nvm-config found, run with original fw/config */
+ ret = 0;
}
/* Setup bdaddr */
--
2.14.1
[PATCH AUTOSEL for 4.4 073/101] net: hns: fix ethtool_get_strings overflow in hns driver
From: Timmy Li
[ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.
When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt
start=801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b
ppe1_tx_pkt.
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b
ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f
ty.kppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69
pkt_err_csum_fai
Signed-off-by: Timmy Li
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index b8517b00e706..a20bd8362712 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -648,7 +648,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)
static int hns_gmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_gmac_stats_string);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 67f33f185a44..6634aef0e841 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -384,7 +384,7 @@ void hns_ppe_update_stats(struct hns_ppe_cb *ppe_cb)
int hns_ppe_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ETH_PPE_STATIC_NUM;
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 4db32c62f062..1d5b18d7a1d7 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -807,7 +807,7 @@ void hns_rcb_get_stats(struct hnae_queue *queue, u64 *data)
*/
int hns_rcb_get_ring_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return HNS_RING_STATIC_REG_NUM;
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index 802d55457f19..b1a27aef4425 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -776,7 +776,7 @@ static void hns_xgmac_get_strings(u32 stringset, u8 *data)
*/
static int hns_xgmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_xgmac_stats_string);
return 0;
--
2.14.1
[PATCH AUTOSEL for 4.4 077/101] perf tests kmod-path: Don't fail if compressed modules aren't supported
From: Kim Phillips
[ Upstream commit 805b151a1afd24414706a7f6ae275fbb9649be74 ]
__kmod_path__parse() uses is_supported_compression() to determine and
parse out compressed module file extensions. On systems without zlib,
this test fails and __kmod_path__parse() continues to strcmp "ko" with
"gz". Don't do this on those systems.
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Peter Zijlstra
Fixes: 3c8a67f50a1e ("perf tools: Add kmod_path__parse function")
Link: http://lkml.kernel.org/r/20170503131402.c66e314460026c80cd787...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/tests/kmod-path.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index 08c433b4bf4f..25e80c02230b 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -60,6 +60,7 @@ int test__kmod_path__parse(void)
M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("///x-x.ko", PERF_RECORD_MISC_USER, false);
+#ifdef HAVE_ZLIB_SUPPORT
/* pathalloc_name alloc_ext kmod comp name ext */
T("///x.ko.gz", true , true , true, true, "[x]", "gz");
T("///x.ko.gz", false, true , true, true, NULL , "gz");
@@ -95,6 +96,7 @@ int test__kmod_path__parse(void)
M("x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
M("x.ko.gz", PERF_RECORD_MISC_USER, false);
+#endif
/* pathalloc_name alloc_ext kmod comp name
ext */
T("[test_module]", true , true , true, false, "[test_module]",
NULL);
--
2.14.1
Re: mmotm 2018-03-07-16-19 uploaded (UML & memcg)
Hi Andrew, On Wed, 7 Mar 2018 18:41:41 -0800 Andrew Morton wrote: > > On Wed, 7 Mar 2018 18:20:12 -0800 Randy Dunlap wrote: > > > On 03/07/2018 04:20 PM, a...@linux-foundation.org wrote: > > > The mm-of-the-moment snapshot 2018-03-07-16-19 has been uploaded to > > > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > > > mmotm-readme.txt says > > > > > > README for mm-of-the-moment: > > > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > > more than once a week. > > > > UML on i386 and/or x86_64: > > > > defconfig, CONFIG_MEMCG is not set: > > > > ../fs/notify/group.c: In function 'fsnotify_final_destroy_group': > > ../fs/notify/group.c:41:24: error: dereferencing pointer to incomplete type > >css_put(&group->memcg->css); > > oops. > > From: Andrew Morton > Subject: fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix > > fix CONFIG_MEMCG=n build > > Reported-by: Randy Dunlap > Cc: Amir Goldstein > Cc: Christoph Lameter > Cc: David Rientjes > Cc: Greg Thelen > Cc: Jan Kara > Cc: Johannes Weiner > Cc: Joonsoo Kim > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Pekka Enberg > Cc: Shakeel Butt > Cc: Vladimir Davydov > Cc: Vlastimil Babka > Signed-off-by: Andrew Morton > --- > > fs/notify/group.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/fs/notify/group.c~fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix > +++ a/fs/notify/group.c > @@ -38,7 +38,7 @@ static void fsnotify_final_destroy_group > group->ops->free_group_priv(group); > > if (group->memcg) > - css_put(&group->memcg->css); > + mem_cgroup_put(group->memcg); > > kfree(group); > } I have applied that to linux-next today. -- Cheers, Stephen Rothwell pgpBRci7ycUrV.pgp Description: OpenPGP digital signature
[PATCH AUTOSEL for 4.4 081/101] RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()
From: Geert Uytterhoeven
[ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ]
With gcc-4.1.2:
drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’:
drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used
uninitialized in this function
Indeed, if nl_client is not found in any of the scanned has buckets, ret
will be used uninitialized.
Preinitialize ret to -EINVAL to fix this.
Fixes: 30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user
space service")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Tatyana Nikolova
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/iwpm_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/core/iwpm_util.c
b/drivers/infiniband/core/iwpm_util.c
index fb43a242847b..8d7d110d0721 100644
--- a/drivers/infiniband/core/iwpm_util.c
+++ b/drivers/infiniband/core/iwpm_util.c
@@ -663,6 +663,7 @@ int iwpm_send_mapinfo(u8 nl_client, int iwpm_pid)
}
skb_num++;
spin_lock_irqsave(&iwpm_mapinfo_lock, flags);
+ ret = -EINVAL;
for (i = 0; i < IWPM_MAPINFO_HASH_SIZE; i++) {
hlist_for_each_entry(map_info, &iwpm_hash_bucket[i],
hlist_node) {
--
2.14.1
[PATCH AUTOSEL for 4.4 083/101] media: bt8xx: Fix err 'bt878_probe()'
From: Christophe JAILLET
[ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ]
This is odd to call 'pci_disable_device()' in an error path before a
coresponding successful 'pci_enable_device()'.
Return directly instead.
Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow")
Signed-off-by: Christophe JAILLET
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/pci/bt8xx/bt878.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bt878.c b/drivers/media/pci/bt8xx/bt878.c
index 8aa726651630..90f05b56 100644
--- a/drivers/media/pci/bt8xx/bt878.c
+++ b/drivers/media/pci/bt8xx/bt878.c
@@ -422,8 +422,7 @@ static int bt878_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
bt878_num);
if (bt878_num >= BT878_MAX) {
printk(KERN_ERR "bt878: Too many devices inserted\n");
- result = -ENOMEM;
- goto fail0;
+ return -ENOMEM;
}
if (pci_enable_device(dev))
return -EIO;
--
2.14.1
[PATCH AUTOSEL for 4.4 079/101] media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt
From: "Gustavo A. R. Silva"
[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]
_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.
This issue was detected with the help of Coccinelle.
Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
Signed-off-by: Gustavo A. R. Silva
Acked-by: Patrice Chotard
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index 8490a65ae1c6..a43404cad3e3 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(unsigned long
ac8sectpfei)
static void channel_swdemux_tsklet(unsigned long data)
{
struct channel_info *channel = (struct channel_info *)data;
- struct c8sectpfei *fei = channel->fei;
+ struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
if (unlikely(!channel || !channel->irec))
return;
+ fei = channel->fei;
+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
--
2.14.1
[PATCH AUTOSEL for 4.4 080/101] drm/msm: fix leak in failed get_pages
From: Prakash Kamliya
[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]
get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.
Signed-off-by: Prakash Kamliya
Signed-off-by: Sharat Masetty
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c76cc853b08a..644faf3ae93a 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -89,14 +89,17 @@ static struct page **get_pages(struct drm_gem_object *obj)
return p;
}
+ msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+ void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
- return ERR_CAST(msm_obj->sgt);
+ msm_obj->sgt = NULL;
+ return ptr;
}
- msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
* because display controller, GPU, etc. are not coherent:
*/
@@ -119,7 +122,10 @@ static void put_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
- sg_free_table(msm_obj->sgt);
+
+ if (msm_obj->sgt)
+ sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);
if (use_pages(obj))
--
2.14.1
[PATCH AUTOSEL for 4.4 085/101] cros_ec: fix nul-termination for firmware build info
From: Arnd Bergmann
[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript
4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
This changes the code back to what it did before changing to a
zero-length array structure.
Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann
Signed-off-by: Benson Leung
Signed-off-by: Sasha Levin
---
drivers/platform/chrome/cros_ec_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_sysfs.c
b/drivers/platform/chrome/cros_ec_sysfs.c
index f3baf9973989..24f1630a8b3f 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -187,7 +187,7 @@ static ssize_t show_ec_version(struct device *dev,
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info:EC error %d\n", msg->result);
else {
- msg->data[sizeof(msg->data) - 1] = '\0';
+ msg->data[EC_HOST_PARAM_SIZE - 1] = '\0';
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info:%s\n", msg->data);
}
--
2.14.1
[PATCH AUTOSEL for 4.4 086/101] platform/chrome: Use proper protocol transfer function
From: Shawn Nematbakhsh
[ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]
pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.
Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh
Signed-off-by: Brian Norris
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Benson Leung
Signed-off-by: Sasha Levin
---
drivers/platform/chrome/cros_ec_proto.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index 92430f781eb7..a0b8c8a8c323 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -59,12 +59,14 @@ static int send_command(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
int ret;
+ int (*xfer_fxn)(struct cros_ec_device *ec, struct cros_ec_command *msg);
if (ec_dev->proto_version > 2)
- ret = ec_dev->pkt_xfer(ec_dev, msg);
+ xfer_fxn = ec_dev->pkt_xfer;
else
- ret = ec_dev->cmd_xfer(ec_dev, msg);
+ xfer_fxn = ec_dev->cmd_xfer;
+ ret = (*xfer_fxn)(ec_dev, msg);
if (msg->result == EC_RES_IN_PROGRESS) {
int i;
struct cros_ec_command *status_msg;
@@ -87,7 +89,7 @@ static int send_command(struct cros_ec_device *ec_dev,
for (i = 0; i < EC_COMMAND_RETRIES; i++) {
usleep_range(1, 11000);
- ret = ec_dev->cmd_xfer(ec_dev, status_msg);
+ ret = (*xfer_fxn)(ec_dev, status_msg);
if (ret < 0)
break;
--
2.14.1
[PATCH AUTOSEL for 4.4 087/101] mmc: avoid removing non-removable hosts during suspend
From: Daniel Drake
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]
The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.
After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.
The conditions here are:
1. During suspend, we reach mmc_pm_notify()
2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
-ENOSYS because btsdio_driver does not have a suspend method.
3. mmc_pm_notify() proceeds to remove the card
4. Upon resume, mmc_rescan() does nothing with this host, because of
the rescan_entered check which aims to only scan a non-removable
device a single time (i.e. during boot).
Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.
Signed-off-by: Daniel Drake
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
---
drivers/mmc/core/core.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5f7d10ba498a..299a83f1ad38 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2791,6 +2791,14 @@ int mmc_pm_notify(struct notifier_block *notify_block,
if (!err)
break;
+ if (!mmc_card_is_removable(host)) {
+ dev_warn(mmc_dev(host),
+"pre_suspend failed for non-removable host: "
+"%d\n", err);
+ /* Avoid removing non-removable hosts */
+ break;
+ }
+
/* Calling bus_ops->remove() with a claimed host can deadlock */
host->bus_ops->remove(host);
mmc_claim_host(host);
--
2.14.1
[PATCH AUTOSEL for 4.4 082/101] rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
From: Tsang-Shian Lin
[ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ]
Reset the driver current tx read/write index to zero when inactiveps
nic out of sync with HW state. Wrong driver tx read/write index will
cause Tx fail.
Signed-off-by: Tsang-Shian Lin
Signed-off-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Cc: Yan-Hsuan Chuang
Cc: Birming Chiu
Cc: Shaofu
Cc: Steven Ting
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index c48b7e8ee0d6..b51815eccdb3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,14 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
+
+ if (rtlpriv->use_new_trx_flow) {
+ rtlpci->tx_ring[i].cur_tx_rp = 0;
+ rtlpci->tx_ring[i].cur_tx_wp = 0;
+ }
+
ring->idx = 0;
+ ring->entries = rtlpci->txringcount[i];
}
}
spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags);
--
2.14.1
[PATCH AUTOSEL for 4.4 093/101] pty: cancel pty slave port buf's work in tty_release
From: Sahara [ Upstream commit 2b022ab7542df60021ab57854b3faaaf42552eaf ] In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc could return without a problem by checking if tty is NULL. CPU 0 CPU 1 - - release_tty pty_write cancel_work_sync(tty) to = tty->link tty_kref_put(tty->link) tty_schedule_flip(to->port) << workqueue >> ... release_one_tty ... pty_cleanup ... kfree(tty->link->port) << workqueue >> flush_to_ldisc tty = READ_ONCE(port->itty) tty is 0x6b6b6b6b6b6b6b6b !!PANIC!! access tty->ldisc Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93 pgd = ffc0eb1c3000 [6b6b6b6b6b6b6b93] *pgd=, *pud= [ cut here ] Kernel BUG at ff800851154c [verbose debug info unavailable] Internal error: Oops - BUG: 9604 [#1] PREEMPT SMP CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: GW 3.18.31-g0a58eeb #1 Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT) Workqueue: events_unbound flush_to_ldisc task: ffc0ed610ec0 ti: ffc0ed624000 task.ti: ffc0ed624000 PC is at ldsem_down_read_trylock+0x0/0x4c LR is at tty_ldisc_ref+0x24/0x4c pc : [] lr : [] pstate: 80400145 sp : ffc0ed627cd0 x29: ffc0ed627cd0 x28: x27: ff8009e05000 x26: ffc0d382cfa0 x25: x24: ff800a012f08 x23: x22: ffc0703fbc88 x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93 x19: x18: 0001 x17: 00e8f80d6f53 x16: 0001 x15: 007f7d826fff x14: 00a0 x13: x12: 0109 x11: x10: x9 : ffc0ed624000 x8 : ffc0ed611580 x7 : x6 : ff800a42e000 x5 : 03fc x4 : 03bd1201 x3 : 0001 x2 : 0001 x1 : ff800851004c x0 : 6b6b6b6b6b6b6b93 Signed-off-by: Sahara Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/tty/tty_io.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 1bb629ab8ecc..a638c1738547 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1694,6 +1694,8 @@ static void release_tty(struct tty_struct *tty, int idx) if (tty->link) tty->link->port->itty = NULL; tty_buffer_cancel_work(tty->port); + if (tty->link) + tty_buffer_cancel_work(tty->link->port); tty_kref_put(tty->link); tty_kref_put(tty); -- 2.14.1
[PATCH AUTOSEL for 4.4 094/101] coresight: Fix disabling of CoreSight TPIU
From: Robert Walker
[ Upstream commit 11595db8e17faaa05fadc25746c870e31276962f ]
The CoreSight TPIU should be disabled when tracing to other sinks to allow
them to operate at full bandwidth.
This patch fixes tpiu_disable_hw() to correctly disable the TPIU by
configuring the TPIU to stop on flush, initiating a manual flush, waiting
for the flush to complete and then waits for the TPIU to indicate it has
stopped.
Signed-off-by: Robert Walker
Tested-by: Mike Leach
Signed-off-by: Mathieu Poirier
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c
b/drivers/hwtracing/coresight/coresight-tpiu.c
index 7214efd10db5..22e10b7d505d 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -45,8 +45,11 @@
#define TPIU_ITATBCTR0 0xef8
/** register definition **/
+/* FFSR - 0x300 */
+#define FFSR_FT_STOPPEDBIT(1)
/* FFCR - 0x304 */
#define FFCR_FON_MAN BIT(6)
+#define FFCR_STOP_FI BIT(12)
/**
* @base: memory mapped base address for this component.
@@ -85,10 +88,14 @@ static void tpiu_disable_hw(struct tpiu_drvdata *drvdata)
{
CS_UNLOCK(drvdata->base);
- /* Clear formatter controle reg. */
- writel_relaxed(0x0, drvdata->base + TPIU_FFCR);
+ /* Clear formatter and stop on flush */
+ writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR);
/* Generate manual flush */
- writel_relaxed(FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ /* Wait for flush to complete */
+ coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0);
+ /* Wait for formatter to stop */
+ coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1);
CS_LOCK(drvdata->base);
}
--
2.14.1
[PATCH AUTOSEL for 4.4 090/101] IB/umem: Fix use of npages/nmap fields
From: Artemy Kovalyov
[ Upstream commit edf1a84fe37c51290e2c88154ecaf48dadff3d27 ]
In ib_umem structure npages holds original number of sg entries, while
nmap is number of DMA blocks returned by dma_map_sg.
Fixes: c5d76f130b28 ('IB/core: Add umem function to read data from user-space')
Signed-off-by: Artemy Kovalyov
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/umem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 0ae337bec4f2..6790ebb366dd 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -354,7 +354,7 @@ int ib_umem_copy_from(void *dst, struct ib_umem *umem,
size_t offset,
return -EINVAL;
}
- ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->nmap, dst, length,
+ ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->npages, dst, length,
offset + ib_umem_offset(umem));
if (ret < 0)
--
2.14.1
[PATCH AUTOSEL for 4.4 092/101] drm/omap: DMM: Check for DMM readiness after successful transaction commit
From: Peter Ujfalusi
[ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ]
Check the status of the DMM engine after it is reported that the
transaction was completed as in rare cases the engine might not reached a
working state.
The wait_status() will print information in case the DMM is not reached the
expected state and the dmm_txn_commit() will return with an error code to
make sure that we are not continuing with a broken setup.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Tomi Valkeinen
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index f516b5891932..083db3f5181f 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -288,7 +288,12 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
msecs_to_jiffies(100))) {
dev_err(dmm->dev, "timed out waiting for done\n");
ret = -ETIMEDOUT;
+ goto cleanup;
}
+
+ /* Check the engine status before continue */
+ ret = wait_status(engine, DMM_PATSTATUS_READY |
+ DMM_PATSTATUS_VALID | DMM_PATSTATUS_DONE);
}
cleanup:
--
2.14.1
[PATCH AUTOSEL for 4.4 096/101] iommu/vt-d: clean up pr_irq if request_threaded_irq fails
From: Jerry Snitselaar [ Upstream commit 72d548113881dd32bf7f0b221d031e6586468437 ] It is unlikely request_threaded_irq will fail, but if it does for some reason we should clear iommu->pr_irq in the error path. Also intel_svm_finish_prq shouldn't try to clean up the page request interrupt if pr_irq is 0. Without these, if request_threaded_irq were to fail the following occurs: fail with no fixes: [0.683147] [ cut here ] [0.683148] NULL pointer, cannot free irq [0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140 [0.683160] Modules linked in: [0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3 [0.683165] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140 [0.683169] RSP: :c9037ce8 EFLAGS: 00010292 [0.683171] RAX: 001d RBX: 880276283c00 RCX: 81c5e5e8 [0.683172] RDX: 0001 RSI: 0096 RDI: 0246 [0.683174] RBP: 880276283c00 R08: R09: 023c [0.683175] R10: 0007 R11: R12: 007a [0.683176] R13: 0001 R14: R15: 01001000 [0.683178] FS: () GS:88027ec8() knlGS: [0.683180] CS: 0010 DS: ES: CR0: 80050033 [0.683181] CR2: CR3: 01c09001 CR4: 003606e0 [0.683182] Call Trace: [0.683189] intel_svm_finish_prq+0x3c/0x60 [0.683191] free_dmar_iommu+0x1ac/0x1b0 [0.683195] init_dmars+0xaaa/0xaea [0.683200] ? klist_next+0x19/0xc0 [0.683203] ? pci_do_find_bus+0x50/0x50 [0.683205] ? pci_get_dev_by_id+0x52/0x70 [0.683208] intel_iommu_init+0x498/0x5c7 [0.683211] pci_iommu_init+0x13/0x3c [0.683214] ? e820__memblock_setup+0x61/0x61 [0.683217] do_one_initcall+0x4d/0x1a0 [0.683220] kernel_init_freeable+0x186/0x20e [0.683222] ? set_debug_rodata+0x11/0x11 [0.683225] ? rest_init+0xb0/0xb0 [0.683226] kernel_init+0xa/0xff [0.683229] ret_from_fork+0x1f/0x30 [0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5 e c3 0f 1f 44 00 00 66 2e 0f 1f 84 [0.683285] ---[ end trace f7650e42792627ca ]--- with iommu->pr_irq = 0, but no check in intel_svm_finish_prq: [0.669561] [ cut here ] [0.669563] Trying to free already-free IRQ 0 [0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0 [0.669574] Modules linked in: [0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4 [0.669579] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [0.669581] RIP: 0010:__free_irq+0xa4/0x2c0 [0.669582] RSP: :c9037cc0 EFLAGS: 00010082 [0.669584] RAX: 0021 RBX: RCX: 81c5e5e8 [0.669585] RDX: 0001 RSI: 0086 RDI: 0046 [0.669587] RBP: R08: R09: 023c [0.669588] R10: 0007 R11: R12: 880276253960 [0.669589] R13: 8802762538a4 R14: 880276253800 R15: 880276283600 [0.669593] FS: () GS:88027ed8() knlGS: [0.669594] CS: 0010 DS: ES: CR0: 80050033 [0.669596] CR2: CR3: 01c09001 CR4: 003606e0 [0.669602] Call Trace: [0.669616] free_irq+0x30/0x60 [0.669620] intel_svm_finish_prq+0x34/0x60 [0.669623] free_dmar_iommu+0x1ac/0x1b0 [0.669627] init_dmars+0xaaa/0xaea [0.669631] ? klist_next+0x19/0xc0 [0.669634] ? pci_do_find_bus+0x50/0x50 [0.669637] ? pci_get_dev_by_id+0x52/0x70 [0.669639] intel_iommu_init+0x498/0x5c7 [0.669642] pci_iommu_init+0x13/0x3c [0.669645] ? e820__memblock_setup+0x61/0x61 [0.669648] do_one_initcall+0x4d/0x1a0 [0.669651] kernel_init_freeable+0x186/0x20e [0.669653] ? set_debug_rodata+0x11/0x11 [0.669656] ? rest_init+0xb0/0xb0 [0.669658] kernel_init+0xa/0xff [0.669661] ret_from_fork+0x1f/0x30 [0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e 8 0e 4c 68 00 49 8b 46 40 48 8b 80 [0.669688] ---[ end trace 58a470248700f2fc ]--- Cc: Alex Williamson Cc: Joerg Roedel Cc: Ashok Raj Signed-off-by: Jerry Snitselaar Reviewed-by: Ashok Raj Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin --- drivers/iommu/intel-svm.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/
Re: ivtv: use arch_phys_wc_add() and require PAT disabled
On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote: > On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote: > > On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote: > > > > > > Ah, I see. So my proposed ioremap_wc call was only "working" by aliasing > the > > > ioremap_nocache()'d mem area and not actually using write combining at > all. > > > > There are some debugging PAT toys out there I think but I haven't played > with > > them yet or I forgot how to to confirm or deny this sort of effort, but > > likeley. > > In fact come to think of it I believe some neurons are telling me that if > two type does not match we'd get an error? I based my guess on some text i read in "PATting Linux" [1]: "ioremap interfaces will succeed if there is an existing, more lenient mapping. Example: If there is an existing uncached mapping to a physical range, any request for write-back or write-combine mapping will succeed, but will eventually map the memory as uncached" But I will try to get some debugpat going to confirm. [1] = https://www.kernel.org/doc/ols/2008/ols2008v2-pages-135-144.pdf > > So unless there is a io-re-remap to change the caching status of a subset of > > the decoder's memory once we find out what the framebuffer offset is inside > > the original iremap_nocache'd area, then its a no go for write combining to > > the framebuffer with PAT. > > No what if the framebuffer driver is just requested as a secondary step > after firmware loading? Its a possibility. The decoder firmware gets loaded at the beginning of the decoder memory range and we know its length, so its possible to ioremap_nocache enough room for the firmware only on init and then ioremap the remaining non-firmware decoder memory areas appropriately after the firmware load succeeds... > > > On the other hand, it works fine for me with a nocache'd framebuffer. It's > > > certainly better for me personally to have a nocache framebuffer with > > > PAT-enabled than the framebuffer completely disabled with PAT-enabled, > > > but I > > > don't think I would even propose to rollback the x86 nopat requirement in > > > general. Apparently the throngs of people using this super-popular driver > > > feature haven't complained in the last couple years, so maybe its OK for > > > me > > > to just patch the pat-enabled guard out and deal with a nocache'd > > > framebuffer. > > > > Nope, best you add a feature to just let you disable wc stuff, to enable > > life with PAT. I'm not sure I understand what you mean. Perhaps the easy answer is to change the fatal is-pat-enabled check to just a warning like "you have PAT enabled, so wc is disabled for the framebuffer. if you want wc, use the nopat parameter"? - Nick
[PATCH AUTOSEL for 4.4 097/101] ip6_vti: adjust vti mtu according to mtu of lower device
From: Alexey Kodanev
[ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ]
LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over
ip6_vti that require fragmentation and the underlying device has an
MTU smaller than 1500 plus some extra space for headers. This happens
because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating
it depending on a destination address or link parameter. Further
attempts to send UDP packets may succeed because pmtu gets updated on
ICMPV6_PKT_TOOBIG in vti6_err().
In case the lower device has larger MTU size, e.g. 9000, ip6_vti works
but not using the possible maximum size, output packets have 1500 limit.
The above cases require manual MTU setup after ip6_vti creation. However
ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev().
Here is the example when the lower device MTU is set to 9000:
# ip a sh ltp_ns_veth2
ltp_ns_veth2@if7: mtu 9000 ...
inet 10.0.0.2/24 scope global ltp_ns_veth2
inet6 fd00::2/64 scope global
# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: mtu 1500 ...
link/tunnel6 fd00::2 peer fd00::1
After the patch:
# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: mtu 8832 ...
link/tunnel6 fd00::2 peer fd00::1
Reported-by: Petr Vorel
Signed-off-by: Alexey Kodanev
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/ipv6/ip6_vti.c | 20
1 file changed, 20 insertions(+)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index d7105422bc63..e4b0fb2f06a3 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -614,6 +614,7 @@ static void vti6_link_config(struct ip6_tnl *t)
{
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = &t->parms;
+ struct net_device *tdev = NULL;
memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr));
memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr));
@@ -626,6 +627,25 @@ static void vti6_link_config(struct ip6_tnl *t)
dev->flags |= IFF_POINTOPOINT;
else
dev->flags &= ~IFF_POINTOPOINT;
+
+ if (p->flags & IP6_TNL_F_CAP_XMIT) {
+ int strict = (ipv6_addr_type(&p->raddr) &
+ (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
+ struct rt6_info *rt = rt6_lookup(t->net,
+&p->raddr, &p->laddr,
+p->link, strict);
+
+ if (rt)
+ tdev = rt->dst.dev;
+ ip6_rt_put(rt);
+ }
+
+ if (!tdev && p->link)
+ tdev = __dev_get_by_index(t->net, p->link);
+
+ if (tdev)
+ dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
+IPV6_MIN_MTU);
}
/**
--
2.14.1
[PATCH AUTOSEL for 4.4 091/101] vgacon: Set VGA struct resource types
From: Bjorn Helgaas
[ Upstream commit c82084117f79bcae085e40da526253736a247120 ]
Set the resource type when we reserve VGA-related I/O port resources.
The resource code doesn't actually look at the type, so it inserts
resources without a type in the tree correctly even without this change.
But if we ever print a resource without a type, it looks like this:
vga+ [??? 0x03c0-0x03df flags 0x0]
Setting the type means it will be printed correctly as:
vga+ [io 0x03c0-0x03df]
Signed-off-by: Bjorn Helgaas
Signed-off-by: Sasha Levin
---
arch/alpha/kernel/console.c| 1 +
drivers/video/console/vgacon.c | 34 ++
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/alpha/kernel/console.c b/arch/alpha/kernel/console.c
index 6a61deed4a85..ab228ed45945 100644
--- a/arch/alpha/kernel/console.c
+++ b/arch/alpha/kernel/console.c
@@ -20,6 +20,7 @@
struct pci_controller *pci_vga_hose;
static struct resource alpha_vga = {
.name = "alpha-vga+",
+ .flags = IORESOURCE_IO,
.start = 0x3C0,
.end= 0x3DF
};
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 517f565b65d7..598ec7545e84 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -409,7 +409,10 @@ static const char *vgacon_startup(void)
vga_video_port_val = VGA_CRT_DM;
if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) {
static struct resource ega_console_resource =
- { .name = "ega", .start = 0x3B0, .end = 0x3BF };
+ { .name = "ega",
+ .flags= IORESOURCE_IO,
+ .start= 0x3B0,
+ .end = 0x3BF };
vga_video_type = VIDEO_TYPE_EGAM;
vga_vram_size = 0x8000;
display_desc = "EGA+";
@@ -417,9 +420,15 @@ static const char *vgacon_startup(void)
&ega_console_resource);
} else {
static struct resource mda1_console_resource =
- { .name = "mda", .start = 0x3B0, .end = 0x3BB };
+ { .name = "mda",
+ .flags= IORESOURCE_IO,
+ .start= 0x3B0,
+ .end = 0x3BB };
static struct resource mda2_console_resource =
- { .name = "mda", .start = 0x3BF, .end = 0x3BF };
+ { .name = "mda",
+ .flags= IORESOURCE_IO,
+ .start= 0x3BF,
+ .end = 0x3BF };
vga_video_type = VIDEO_TYPE_MDA;
vga_vram_size = 0x2000;
display_desc = "*MDA";
@@ -441,15 +450,21 @@ static const char *vgacon_startup(void)
vga_vram_size = 0x8000;
if (!screen_info.orig_video_isVGA) {
- static struct resource ega_console_resource
- = { .name = "ega", .start = 0x3C0, .end =
0x3DF };
+ static struct resource ega_console_resource =
+ { .name = "ega",
+ .flags= IORESOURCE_IO,
+ .start= 0x3C0,
+ .end = 0x3DF };
vga_video_type = VIDEO_TYPE_EGAC;
display_desc = "EGA";
request_resource(&ioport_resource,
&ega_console_resource);
} else {
- static struct resource vga_console_resource
- = { .name = "vga+", .start = 0x3C0, .end =
0x3DF };
+ static struct resource vga_console_resource =
+ { .name = "vga+",
+ .flags= IORESOURCE_IO,
+ .start= 0x3C0,
+ .end = 0x3DF };
vga_video_type = VIDEO_TYPE_VGAC;
display_desc = "VGA+";
request_resource(&ioport_resource,
@@ -493,7 +508,10 @@ static const char *vgacon_startup(void)
}
} else {
static struct resource cga_console_resource =
- { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
+ { .name = "cga",
+ .flags= IORESOURCE_IO,
+
[PATCH AUTOSEL for 4.4 099/101] nfsd4: permit layoutget of executable-only files
From: Benjamin Coddington
[ Upstream commit 66282ec1cf004c09083c29cb5e49019037937bbd ]
Clients must be able to read a file in order to execute it, and for pNFS
that means the client needs to be able to perform a LAYOUTGET on the file.
This behavior for executable-only files was added for OPEN in commit
a043226bc140 "nfsd4: permit read opens of executable-only files".
This fixes up xfstests generic/126 on block/scsi layouts.
Signed-off-by: Benjamin Coddington
Signed-off-by: J. Bruce Fields
Signed-off-by: Sasha Levin
---
fs/nfsd/nfs4proc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 209dbfc50cd4..bfbee8ddf978 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1245,14 +1245,14 @@ nfsd4_layoutget(struct svc_rqst *rqstp,
const struct nfsd4_layout_ops *ops;
struct nfs4_layout_stateid *ls;
__be32 nfserr;
- int accmode;
+ int accmode = NFSD_MAY_READ_IF_EXEC;
switch (lgp->lg_seg.iomode) {
case IOMODE_READ:
- accmode = NFSD_MAY_READ;
+ accmode |= NFSD_MAY_READ;
break;
case IOMODE_RW:
- accmode = NFSD_MAY_READ | NFSD_MAY_WRITE;
+ accmode |= NFSD_MAY_READ | NFSD_MAY_WRITE;
break;
default:
dprintk("%s: invalid iomode %d\n",
--
2.14.1
[PATCH AUTOSEL for 4.4 101/101] dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63
From: Vignesh R
[ Upstream commit d087f15786021a9605b20f4c678312510be4cac1 ]
Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
lowest numbered event is at the lowest byte address and highest numbered
event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
different, in that the lowest numbered event is at the highest address
and highest numbered event is at the lowest address. Therefore, modify
ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
accordingly.
Signed-off-by: Vignesh R
Signed-off-by: Peter Ujfalusi
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
---
drivers/dma/ti-dma-crossbar.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 8100ede095d5..c7bd1c5315f4 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -51,7 +51,15 @@ struct ti_am335x_xbar_map {
static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val, iomem + event);
+ /*
+* TPCC_EVT_MUX_60_63 register layout is different than the
+* rest, in the sense, that event 63 is mapped to lowest byte
+* and event 60 is mapped to highest, handle it separately.
+*/
+ if (event >= 60 && event <= 63)
+ writeb_relaxed(val, iomem + (63 - event % 4));
+ else
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
--
2.14.1
Re: [PATCH v2] perf annotate: Support to display the IPC/Cycle in tui mode
Hi,
Could this patch be accepted?
I'm working on the supporting for stdio mode. I just wish to post the
patch series after this patch being merged.
Thanks
Jin Yao
On 2/27/2018 5:38 PM, Jin Yao wrote:
Unlike the perf report interactive annotate mode, the perf annotate
doesn't display the IPC/Cycle even if branch info is recorded in perf
data file.
perf record -b ...
perf annotate function
It should show IPC/cycle, but it doesn't.
This patch lets perf annotate support the displaying of IPC/Cycle if
branch info is in perf data.
For example,
perf annotate compute_flag
Percent│ IPC Cycle
│
│
│Disassembly of section .text:
│
│00400640 :
│compute_flag():
│volatile int count;
│static unsigned int s_randseed;
│
│__attribute__((noinline))
│int compute_flag()
│{
22.96 │1.18 584sub$0x8,%rsp
│int i;
│
│i = rand() % 2;
23.02 │1.18 1 → callq rand@plt
│
│return i;
27.05 │3.37 mov%eax,%edx
│}
│3.37 add$0x8,%rsp
│{
│int i;
│
│i = rand() % 2;
│
│return i;
│3.37 shr$0x1f,%edx
│3.37 add%edx,%eax
│3.37 and$0x1,%eax
│3.37 sub%edx,%eax
│}
26.97 │3.37 2 ← retq
Note that, this patch only supports tui mode. For stdio,
now it just keeps original behavior. Will support it in a
follow-up patch.
perf annotate compute_flag --stdio
Percent | Source code & Disassembly of div for cycles:ppp (7993 samples)
--
:
:
:
:Disassembly of section .text:
:
:00400640 :
:compute_flag():
:volatile int count;
:static unsigned int s_randseed;
:
:__attribute__((noinline))
:int compute_flag()
:{
0.29 : 400640: sub$0x8,%rsp # +100.00%
:int i;
:
:i = rand() % 2;
42.93 : 400644: callq 400490 # -100.00% (p:100.00%)
:
:return i;
0.10 : 400649: mov%eax,%edx # +100.00%
:}
0.94 : 40064b: add$0x8,%rsp
:{
:int i;
:
:i = rand() % 2;
:
:return i;
27.02 : 40064f: shr$0x1f,%edx
0.15 : 400652: add%edx,%eax
1.24 : 400654: and$0x1,%eax
2.08 : 400657: sub%edx,%eax
:}
25.26 : 400659: retq # -100.00% (p:100.00%)
Change-log:
---
v2:
---
No code change. Just change the patch description to make it more clear.
Signed-off-by: Jin Yao
---
tools/perf/builtin-annotate.c | 88 ---
1 file changed, 82 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index f15731a..ead6ae4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -44,6 +44,7 @@ struct perf_annotate {
bool full_paths;
bool print_line;
bool skip_missing;
+ bool has_br_stack;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -146,16 +147,73 @@ static void process_branch_stack(struct branch_stack *bs,
struct addr_location *
free(bi);
}
+static int hist_iter__branch_callback(struct hist_entry_iter *iter,
+ struct addr_location *al __maybe_unused,
+ bool single __maybe_unused,
+ void *arg __maybe_unused)
+{
+ struct hist_entry *he = iter->he;
+ struct branch_info *bi;
+ struct perf_sample *sample = iter->sample;
+ struct perf_evsel *evsel = iter->evsel;
+ int err;
+
+ hist__account_cycles(sample->branch_stack, al, sample, false);
+
+ bi = he->branch_info;
+ err = addr_map_symbol__inc_samples(&bi->from, sample, evsel->idx);
+
+ if (err)
+ goto out;
+
+ err = addr_map_symbol__inc_samples(&bi->to, sample, evsel->idx);
+
+out:
[PATCH AUTOSEL for 4.4 100/101] clk: si5351: Rename internal plls to avoid name collisions
From: Sergej Sawazki
[ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ]
This drivers probe fails due to a clock name collision if a clock named
'plla' or 'pllb' is already registered when registering this drivers
internal plls.
Fix it by renaming internal plls to avoid name collisions.
Cc: Sebastian Hesselbarth
Cc: Rabeeh Khoury
Signed-off-by: Sergej Sawazki
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/clk-si5351.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e346b223199d..a01ee9a3ed6d 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -72,7 +72,7 @@ static const char * const si5351_input_names[] = {
"xtal", "clkin"
};
static const char * const si5351_pll_names[] = {
- "plla", "pllb", "vxco"
+ "si5351_plla", "si5351_pllb", "si5351_vxco"
};
static const char * const si5351_msynth_names[] = {
"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
--
2.14.1
[PATCH AUTOSEL for 4.4 095/101] pinctrl: Really force states during suspend/resume
From: Florian Fainelli
[ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.
In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().
[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.
Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per
device")
Signed-off-by: Florian Fainelli
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
---
drivers/pinctrl/core.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2686a4450dfc..f4639a9f1e48 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -979,19 +979,16 @@ struct pinctrl_state *pinctrl_lookup_state(struct pinctrl
*p,
EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
/**
- * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * pinctrl_commit_state() - select/activate/program a pinctrl state to HW
* @p: the pinctrl handle for the device that requests configuration
* @state: the state handle to select/activate/program
*/
-int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state)
{
struct pinctrl_setting *setting, *setting2;
struct pinctrl_state *old_state = p->state;
int ret;
- if (p->state == state)
- return 0;
-
if (p->state) {
/*
* For each pinmux setting in the old state, forget SW's record
@@ -1055,6 +1052,19 @@ int pinctrl_select_state(struct pinctrl *p, struct
pinctrl_state *state)
return ret;
}
+
+/**
+ * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
+ */
+int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+{
+ if (p->state == state)
+ return 0;
+
+ return pinctrl_commit_state(p, state);
+}
EXPORT_SYMBOL_GPL(pinctrl_select_state);
static void devm_pinctrl_release(struct device *dev, void *res)
@@ -1223,7 +1233,7 @@ void pinctrl_unregister_map(struct pinctrl_map const *map)
int pinctrl_force_sleep(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep))
- return pinctrl_select_state(pctldev->p, pctldev->hog_sleep);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
@@ -1235,7 +1245,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
int pinctrl_force_default(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default))
- return pinctrl_select_state(pctldev->p, pctldev->hog_default);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_default);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_default);
--
2.14.1
[PATCH AUTOSEL for 3.18 08/53] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA
From: Santeri Toivonen
[ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
Asus laptop X302UA starts up with Wi-Fi disabled,
without a way to enable it. Set wapf=4 to fix the problem.
Signed-off-by: Santeri Toivonen
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Sasha Levin
---
drivers/platform/x86/asus-nb-wmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index abdaed34c728..5ea4c5a72a66 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -99,6 +99,15 @@ static const struct dmi_system_id asus_quirks[] = {
*/
.driver_data = &quirk_asus_wapf4,
},
+ {
+ .callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. X302UA",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X302UA"),
+ },
+ .driver_data = &quirk_asus_wapf4,
+ },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. X401U",
--
2.14.1
[PATCH AUTOSEL for 3.18 03/53] scsi: sg: check for valid direction before starting the request
From: Johannes Thumshirn
[ Upstream commit 28676d869bbb5257b5f14c0c95ad3af3a7019dd5 ]
Check for a valid direction before starting the request, otherwise we
risk running into an assertion in the scsi midlayer checking for valid
requests.
[mkp: fixed typo]
Signed-off-by: Johannes Thumshirn
Link: http://www.spinics.net/lists/linux-scsi/msg104400.html
Reported-by: Dmitry Vyukov
Signed-off-by: Hannes Reinecke
Tested-by: Johannes Thumshirn
Reviewed-by: Christoph Hellwig
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/sg.c | 46 ++
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 783040af3ead..bba2dcd4f324 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -674,18 +674,14 @@ sg_write(struct file *filp, const char __user *buf,
size_t count, loff_t * ppos)
* is a non-zero input_size, so emit a warning.
*/
if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) {
- static char cmd[TASK_COMM_LEN];
- if (strcmp(current->comm, cmd)) {
- printk_ratelimited(KERN_WARNING
- "sg_write: data in/out %d/%d bytes "
- "for SCSI command 0x%x-- guessing "
- "data in;\n program %s not setting
"
- "count and/or reply_len properly\n",
- old_hdr.reply_len -
(int)SZ_SG_HEADER,
- input_size, (unsigned int) cmnd[0],
- current->comm);
- strcpy(cmd, current->comm);
- }
+ printk_ratelimited(KERN_WARNING
+ "sg_write: data in/out %d/%d bytes "
+ "for SCSI command 0x%x-- guessing "
+ "data in;\n program %s not setting "
+ "count and/or reply_len properly\n",
+ old_hdr.reply_len - (int)SZ_SG_HEADER,
+ input_size, (unsigned int) cmnd[0],
+ current->comm);
}
k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
return (k < 0) ? k : count;
@@ -764,6 +760,29 @@ sg_new_write(Sg_fd *sfp, struct file *file, const char
__user *buf,
return count;
}
+static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
+{
+ switch (hp->dxfer_direction) {
+ case SG_DXFER_NONE:
+ if (hp->dxferp || hp->dxfer_len > 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
+ case SG_DXFER_FROM_DEV:
+ case SG_DXFER_TO_FROM_DEV:
+ if (!hp->dxferp || hp->dxfer_len == 0)
+ return false;
+ return true;
+ case SG_DXFER_UNKNOWN:
+ if ((!hp->dxferp && hp->dxfer_len) ||
+ (hp->dxferp && hp->dxfer_len == 0))
+ return false;
+ return true;
+ default:
+ return false;
+ }
+}
+
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -784,6 +803,9 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
+ if (!sg_is_valid_dxfer(hp))
+ return -EINVAL;
+
k = sg_start_req(srp, cmnd);
if (k) {
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
--
2.14.1
[PATCH AUTOSEL for 3.18 09/53] x86: i8259: export legacy_pic symbol
From: Hans de Goede
[ Upstream commit 7ee06cb2f840a96be46233181ed4557901a74385 ]
The classic PC rtc-coms driver has a workaround for broken ACPI device
nodes for it which lack an irq resource. This workaround used to
unconditionally hardcode the irq to 8 in these cases.
This was causing irq conflict problems on systems without a legacy-pic
so a recent patch added an if (nr_legacy_irqs()) guard to the
workaround to avoid this irq conflict.
nr_legacy_irqs() uses the legacy_pic symbol under the hood causing
an undefined symbol error if the rtc-cmos code is build as a module.
This commit exports the legacy_pic symbol to fix this.
Cc: rtc-li...@googlegroups.com
Cc: alexandre.bell...@free-electrons.com
Signed-off-by: Hans de Goede
Signed-off-by: Alexandre Belloni
Signed-off-by: Sasha Levin
---
arch/x86/kernel/i8259.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index e7cc5370cd2f..6c7e7986939a 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -405,6 +405,7 @@ struct legacy_pic default_legacy_pic = {
};
struct legacy_pic *legacy_pic = &default_legacy_pic;
+EXPORT_SYMBOL(legacy_pic);
static int __init i8259A_init_ops(void)
{
--
2.14.1
[PATCH AUTOSEL for 3.18 07/53] wil6210: fix memory access violation in wil_memcpy_from/toio_32
From: Dedy Lansky
[ Upstream commit 0f6edfe259d161580cb4870fcc46f5490f85 ]
In case count is not multiple of 4, there is a read access in
wil_memcpy_toio_32() from outside src buffer boundary.
In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is
a write access to outside dst io memory boundary.
Fix these issues with proper handling of the last 1 to 4 copied bytes.
Signed-off-by: Dedy Lansky
Signed-off-by: Maya Erez
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/wil6210/main.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/main.c
b/drivers/net/wireless/ath/wil6210/main.c
index c5676841fd12..e27dd5017218 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -59,9 +59,15 @@ void wil_memcpy_fromio_32(void *dst, const volatile void
__iomem *src,
u32 *d = dst;
const volatile u32 __iomem *s = src;
- /* size_t is unsigned, if (count%4 != 0) it will wrap */
- for (count += 4; count > 4; count -= 4)
+ for (; count >= 4; count -= 4)
*d++ = __raw_readl(s++);
+
+ if (unlikely(count)) {
+ /* count can be 1..3 */
+ u32 tmp = __raw_readl(s);
+
+ memcpy(d, &tmp, count);
+ }
}
void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src,
@@ -70,8 +76,16 @@ void wil_memcpy_toio_32(volatile void __iomem *dst, const
void *src,
volatile u32 __iomem *d = dst;
const u32 *s = src;
- for (count += 4; count > 4; count -= 4)
+ for (; count >= 4; count -= 4)
__raw_writel(*s++, d++);
+
+ if (unlikely(count)) {
+ /* count can be 1..3 */
+ u32 tmp = 0;
+
+ memcpy(&tmp, s, count);
+ __raw_writel(tmp, d);
+ }
}
static void wil_disconnect_cid(struct wil6210_priv *wil, int cid)
--
2.14.1
[PATCH AUTOSEL for 3.18 04/53] scsi: sg: close race condition in sg_remove_sfp_usercontext()
From: Hannes Reinecke
[ Upstream commit 97d27b0dd015e980ade63fda111fd1353276e28b ]
sg_remove_sfp_usercontext() is clearing any sg requests, but needs to
take 'rq_list_lock' when modifying the list.
Reported-by: Christoph Hellwig
Signed-off-by: Hannes Reinecke
Reviewed-by: Johannes Thumshirn
Tested-by: Johannes Thumshirn
Reviewed-by: Christoph Hellwig
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/sg.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index bba2dcd4f324..cab426720144 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -535,6 +535,7 @@ sg_read(struct file *filp, char __user *buf, size_t count,
loff_t * ppos)
} else
count = (old_hdr->result == 0) ? 0 : -EIO;
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
retval = count;
free_old_hdr:
kfree(old_hdr);
@@ -575,6 +576,7 @@ sg_new_read(Sg_fd * sfp, char __user *buf, size_t count,
Sg_request * srp)
}
err_out:
err2 = sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return err ? : err2 ? : count;
}
@@ -811,6 +813,7 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
"sg_common_write: start_req err=%d\n", k));
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return k; /* probably out of space --> ENOMEM */
}
if (atomic_read(&sdp->detaching)) {
@@ -823,6 +826,7 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
}
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return -ENODEV;
}
@@ -1353,6 +1357,7 @@ sg_rq_end_io_usercontext(struct work_struct *work)
struct sg_fd *sfp = srp->parentfp;
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
kref_put(&sfp->f_ref, sg_remove_sfp);
}
@@ -1902,8 +1907,6 @@ sg_finish_rem_req(Sg_request *srp)
else
sg_remove_scat(sfp, req_schp);
- sg_remove_request(sfp, srp);
-
return ret;
}
@@ -2250,12 +2253,17 @@ sg_remove_sfp_usercontext(struct work_struct *work)
struct sg_fd *sfp = container_of(work, struct sg_fd, ew.work);
struct sg_device *sdp = sfp->parentdp;
Sg_request *srp;
+ unsigned long iflags;
/* Cleanup any responses which were never read(). */
+ write_lock_irqsave(&sfp->rq_list_lock, iflags);
while (!list_empty(&sfp->rq_list)) {
srp = list_first_entry(&sfp->rq_list, Sg_request, entry);
sg_finish_rem_req(srp);
+ list_del(&srp->entry);
+ srp->parentfp = NULL;
}
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
if (sfp->reserve.bufflen > 0) {
SCSI_LOG_TIMEOUT(6, sg_printk(KERN_INFO, sdp,
--
2.14.1
[PATCH AUTOSEL for 3.18 02/53] perf session: Don't rely on evlist in pipe mode
From: David Carrillo-Cisneros
[ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ]
Session sets a number parameters that rely on evlist. These parameters
are not used in pipe-mode and should not be set, since evlist is
unavailable. Fix that.
Signed-off-by: David Carrillo-Cisneros
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: He Kuang
Cc: Masami Hiramatsu
Cc: Paul Turner
Cc: Peter Zijlstra
Cc: Simon Que
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lkml.kernel.org/r/20170410201432.24807-6-davi...@google.com
[ Check if file != NULL in perf_session__new(), like when used by builtin-top.c
]
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/session.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 80dbba095f30..08051ee2116d 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -108,8 +108,14 @@ struct perf_session *perf_session__new(struct
perf_data_file *file,
if (perf_session__open(session) < 0)
goto out_close;
- perf_session__set_id_hdr_size(session);
- perf_session__set_comm_exec(session);
+ /*
+* set session attributes that are present in perf.data
+* but not in pipe-mode.
+*/
+ if (!file->is_pipe) {
+ perf_session__set_id_hdr_size(session);
+ perf_session__set_comm_exec(session);
+ }
}
}
@@ -122,7 +128,11 @@ struct perf_session *perf_session__new(struct
perf_data_file *file,
pr_warning("Cannot read kernel map\n");
}
- if (tool && tool->ordering_requires_timestamps &&
+ /*
+* In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is
+* processed, so perf_evlist__sample_id_all is not meaningful here.
+*/
+ if ((!file || !file->is_pipe) && tool &&
tool->ordering_requires_timestamps &&
tool->ordered_events &&
!perf_evlist__sample_id_all(session->evlist)) {
dump_printf("WARNING: No sample_id_all support, falling back to
unordered processing\n");
tool->ordered_events = false;
--
2.14.1
[PATCH AUTOSEL for 3.18 10/53] Input: ar1021_i2c - fix too long name in driver's device table
From: Dmitry Torokhov
[ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ]
The name field in structure i2c_device_id is 20 characters, and we expect
it to be NULL-terminated, however we are trying to stuff it with 21 bytes
and thus NULL-terminator is lost. This causes issues when one creates
device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
and automatic module loading by alias does not work as result.
The -I2C suffix in the device name is superfluous, we know what bus we are
dealing with, so let's drop it. Also, no other driver uses capitals, and
the manufacturer name is normally not included, except in very rare cases
of incompatible name collisions.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
Reviewed-By: Christian Gmeiner
Tested-by: Martin Kepplinger
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin
---
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c
b/drivers/input/touchscreen/ar1021_i2c.c
index ba30578e296e..845bfda99d74 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_resume(struct device
*dev)
static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume);
static const struct i2c_device_id ar1021_i2c_id[] = {
- { "MICROCHIP_AR1021_I2C", 0 },
+ { "ar1021", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
--
2.14.1
[PATCH AUTOSEL for 4.4 098/101] RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS
From: Anton Vasilyev
[ Upstream commit 744820869166c8c78be891240cf5f66e8a333694 ]
Debugfs file reset_stats is created with S_IRUSR permissions,
but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS,
whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS.
The patch fixes misstype with permissions.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev
Acked-by: Selvin Xavier
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
index 86c303a620c1..748b63b86cbc 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
@@ -834,7 +834,7 @@ void ocrdma_add_port_stats(struct ocrdma_dev *dev)
dev->reset_stats.type = OCRDMA_RESET_STATS;
dev->reset_stats.dev = dev;
- if (!debugfs_create_file("reset_stats", S_IRUSR, dev->dir,
+ if (!debugfs_create_file("reset_stats", 0200, dev->dir,
&dev->reset_stats, &ocrdma_dbg_ops))
goto err;
--
2.14.1
[PATCH AUTOSEL for 3.18 11/53] ACPI/processor: Replace racy task affinity logic
From: Thomas Gleixner
[ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ]
acpi_processor_get_throttling() requires to invoke the getter function on
the target CPU. This is achieved by temporarily setting the affinity of the
calling user space thread to the requested CPU and reset it to the original
affinity afterwards.
That's racy vs. CPU hotplug and concurrent affinity settings for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
acpi_processor_get_throttling() is invoked in two ways:
1) The CPU online callback, which is already running on the target CPU and
obviously protected against hotplug and not affected by affinity
settings.
2) The ACPI driver probe function, which is not protected against hotplug
during modprobe.
Switch it over to work_on_cpu() and protect the probe function against CPU
hotplug.
Signed-off-by: Thomas Gleixner
Cc: Fenghua Yu
Cc: Tony Luck
Cc: Herbert Xu
Cc: "Rafael J. Wysocki"
Cc: Peter Zijlstra
Cc: Benjamin Herrenschmidt
Cc: Sebastian Siewior
Cc: Lai Jiangshan
Cc: linux-a...@vger.kernel.org
Cc: Viresh Kumar
Cc: Michael Ellerman
Cc: Tejun Heo
Cc: "David S. Miller"
Cc: Len Brown
Link: http://lkml.kernel.org/r/20170412201042.785920...@linutronix.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Sasha Levin
---
drivers/acpi/processor_driver.c | 7 -
drivers/acpi/processor_throttling.c | 62 +
2 files changed, 42 insertions(+), 27 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d9f71581b79b..bdc3063f694d 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -231,11 +231,16 @@ static int __acpi_processor_start(struct acpi_device
*device)
static int acpi_processor_start(struct device *dev)
{
struct acpi_device *device = ACPI_COMPANION(dev);
+ int ret;
if (!device)
return -ENODEV;
- return __acpi_processor_start(device);
+ /* Protect against concurrent CPU hotplug operations */
+ get_online_cpus();
+ ret = __acpi_processor_start(device);
+ put_online_cpus();
+ return ret;
}
static int acpi_processor_stop(struct device *dev)
diff --git a/drivers/acpi/processor_throttling.c
b/drivers/acpi/processor_throttling.c
index 84243c32e29c..a92ea0a1c7e4 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -66,8 +66,8 @@ struct acpi_processor_throttling_arg {
#define THROTTLING_POSTCHANGE (2)
static int acpi_processor_get_throttling(struct acpi_processor *pr);
-int acpi_processor_set_throttling(struct acpi_processor *pr,
- int state, bool force);
+static int __acpi_processor_set_throttling(struct acpi_processor *pr,
+ int state, bool force, bool direct);
static int acpi_processor_update_tsd_coord(void)
{
@@ -886,7 +886,8 @@ static int acpi_processor_get_throttling_ptc(struct
acpi_processor *pr)
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Invalid throttling state, reset\n"));
state = 0;
- ret = acpi_processor_set_throttling(pr, state, true);
+ ret = __acpi_processor_set_throttling(pr, state, true,
+ true);
if (ret)
return ret;
}
@@ -896,36 +897,31 @@ static int acpi_processor_get_throttling_ptc(struct
acpi_processor *pr)
return 0;
}
-static int acpi_processor_get_throttling(struct acpi_processor *pr)
+static long __acpi_processor_get_throttling(void *data)
{
- cpumask_var_t saved_mask;
- int ret;
+ struct acpi_processor *pr = data;
+
+ return pr->throttling.acpi_processor_get_throttling(pr);
+}
+static int acpi_processor_get_throttling(struct acpi_processor *pr)
+{
if (!pr)
return -EINVAL;
if (!pr->flags.throttling)
return -ENODEV;
- if (!alloc_cpumask_var(&saved_mask, GFP_KERNEL))
- return -ENOMEM;
-
/*
-* Migrate task to the cpu pointed by pr.
+* This is either called from the CPU hotplug callback of
+* processor_driver or via the ACPI probe function. In the latter
+* case the CPU is not guaranteed to be online. Both call sites are
+* protected against CPU hotplug.
*/
- cpumask_copy(saved_mask, ¤t->cpus_allowed);
- /* FIXME: use work_on_cpu() */
- if (set_cpus_allowed_ptr(current, cpumask_of(pr->id))) {
- /* Can't migrate to the target pr->id CPU. Exit */
- free_cpumask_var(saved_mask);
+ if (!cpu_online(pr->id))
return -ENODEV;
- }
- ret = pr->throttling.acpi_processor_get_th
[PATCH AUTOSEL for 3.18 05/53] kprobes/x86: Fix kprobe-booster not to boost far call instructions
From: Masami Hiramatsu [ Upstream commit bd0b90676c30fe640e7ead919b3e38846ac88ab7 ] Fix the kprobe-booster not to boost far call instruction, because a call may store the address in the single-step execution buffer to the stack, which should be modified after single stepping. Currently, this instruction will be filtered as not boostable in resume_execution(), so this is not a critical issue. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Andrey Ryabinin Cc: Anil S Keshavamurthy Cc: Borislav Petkov Cc: Brian Gerst Cc: David S . Miller Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ye Xiaolong Link: http://lkml.kernel.org/r/149076340615.22469.14066273186134229909.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- arch/x86/kernel/kprobes/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index b6547a441bad..422b76ab0374 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -196,6 +196,8 @@ int can_boost(kprobe_opcode_t *opcodes, void *addr) return (opcode != 0x62 && opcode != 0x67); case 0x70: return 0; /* can't boost conditional jump */ + case 0x90: + return opcode != 0x9a; /* can't boost call far */ case 0xc0: /* can't boost software-interruptions */ return (0xc1 < opcode && opcode < 0xcc) || opcode == 0xcf; -- 2.14.1
[PATCH AUTOSEL for 3.18 15/53] net: ipv6: send unsolicited NA on admin up
From: David Ahern
[ Upstream commit 4a6e3c5def13c91adf2acc613837001f09af3baa ]
ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is
set to 1, gratuitous arp requests are sent when the device is brought up.
The same is expected when ndisc_notify is set to 1 (per ndisc_notify in
Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP
event; add it.
Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer
address change")
Signed-off-by: David Ahern
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/ipv6/ndisc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index a46c50423aec..2e9e0af9e759 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1646,6 +1646,8 @@ static int ndisc_netdev_event(struct notifier_block
*this, unsigned long event,
case NETDEV_CHANGEADDR:
neigh_changeaddr(&nd_tbl, dev);
fib6_run_gc(0, net, false);
+ /* fallthrough */
+ case NETDEV_UP:
idev = in6_dev_get(dev);
if (!idev)
break;
--
2.14.1
[PATCH AUTOSEL for 3.18 14/53] i2c: i2c-scmi: add a MS HID
From: Edgar Cherkasov
[ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]
Description of the problem:
- i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
- the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
Interface Specification, version 1.0": "Each device must specify
'SMBUS01' as its _HID and use a unique _UID value";
- unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
and implement "SMB0001" HID instead of "SMBUS01";
- I speculate that they do this because only "SMB0001" is hard coded in
Windows SMBus driver produced by Microsoft.
This leads to following situation:
- SMBus works out of box in Windows but not in Linux;
- board vendors are forced to add correct "SMBUS01" HID to BIOS to make
SMBus work in Linux. Moreover the same board vendors complain that
tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
and produce errors. So they need to constantly patch the compiler for
each new version of BIOS.
As it is very unlikely that BIOS vendors implement a correct HID in
future, I would propose to consider whether it is possible to work around
the problem by adding MS HID to the Linux i2c-scmi driver.
v2: move the definition of the new HID to the driver itself.
Signed-off-by: Edgar Cherkasov
Signed-off-by: Michael Brunner
Acked-by: Viktor Krasnov
Reviewed-by: Jean Delvare
Reviewed-by: Mika Westerberg
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
---
drivers/i2c/busses/i2c-scmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/busses/i2c-scmi.c b/drivers/i2c/busses/i2c-scmi.c
index dfc98df7b1b6..7aa7b9cb6203 100644
--- a/drivers/i2c/busses/i2c-scmi.c
+++ b/drivers/i2c/busses/i2c-scmi.c
@@ -18,6 +18,9 @@
#define ACPI_SMBUS_HC_CLASS"smbus"
#define ACPI_SMBUS_HC_DEVICE_NAME "cmi"
+/* SMBUS HID definition as supported by Microsoft Windows */
+#define ACPI_SMBUS_MS_HID "SMB0001"
+
ACPI_MODULE_NAME("smbus_cmi");
struct smbus_methods_t {
@@ -51,6 +54,7 @@ static const struct smbus_methods_t ibm_smbus_methods = {
static const struct acpi_device_id acpi_smbus_cmi_ids[] = {
{"SMBUS01", (kernel_ulong_t)&smbus_methods},
{ACPI_SMBUS_IBM_HID, (kernel_ulong_t)&ibm_smbus_methods},
+ {ACPI_SMBUS_MS_HID, (kernel_ulong_t)&smbus_methods},
{"", 0}
};
MODULE_DEVICE_TABLE(acpi, acpi_smbus_cmi_ids);
--
2.14.1
[PATCH AUTOSEL for 3.18 06/53] kprobes/x86: Set kprobes pages read-only
From: Masami Hiramatsu
[ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
Set the pages which is used for kprobes' singlestep buffer
and optprobe's trampoline instruction buffer to readonly.
This can prevent unexpected (or unintended) instruction
modification.
This also passes rodata_test as below.
Without this patch, rodata_test shows a warning:
WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235
note_page+0x7a9/0xa20
x86/mm: Found insecure W+X mapping at address
a000/0xa000
With this fix, no W+X pages are found:
x86/mm: Checked W+X mappings: passed, no W+X pages found.
rodata_test: all tests were successful
Reported-by: Andrey Ryabinin
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Anil S Keshavamurthy
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: David S . Miller
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ye Xiaolong
Link:
http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devbox
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
arch/x86/kernel/kprobes/core.c | 4
arch/x86/kernel/kprobes/opt.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 422b76ab0374..78f221ab8593 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -378,6 +378,8 @@ static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
+ set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Copy an instruction with recovering if other optprobe modifies it.*/
ret = __copy_instruction(p->ainsn.insn, p->addr);
if (!ret)
@@ -392,6 +394,8 @@ static int arch_copy_kprobe(struct kprobe *p)
else
p->ainsn.boostable = -1;
+ set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Check whether the instruction modifies Interrupt Flag or not */
p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index cdb672c3049b..aec5dfa8b7e1 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -344,6 +344,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
*op)
}
buf = (u8 *)op->optinsn.insn;
+ set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
/* Copy instructions into the out-of-line buffer */
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
@@ -366,6 +367,8 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
*op)
synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size,
(u8 *)op->kp.addr + op->optinsn.size);
+ set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
+
flush_icache_range((unsigned long) buf,
(unsigned long) buf + TMPL_END_IDX +
op->optinsn.size + RELATIVEJUMP_SIZE);
--
2.14.1
[PATCH AUTOSEL for 3.18 18/53] ath: Fix updating radar flags for coutry code India
From: Mohammed Shafi Shajakhan
[ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ]
As per latest regulatory update for India, channel 52, 56, 60, 64
is no longer restricted to DFS. Enabling DFS/no infra flags in driver
results in applying all DFS related restrictions (like doing CAC etc
before this channel moves to 'available state') for these channels
even though the country code is programmed as 'India' in he hardware,
fix this by relaxing the frequency range while applying RADAR flags
only if the country code is programmed to India. If the frequency range
needs to modified based on different country code, ath_is_radar_freq
can be extended/modified dynamically.
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/regd.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 06ea6cc9e30a..62077bda8dde 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain)
EXPORT_SYMBOL(ath_is_49ghz_allowed);
/* Frequency is one where radar detection is required */
-static bool ath_is_radar_freq(u16 center_freq)
+static bool ath_is_radar_freq(u16 center_freq,
+ struct ath_regulatory *reg)
+
{
+ if (reg->country_code == CTRY_INDIA)
+ return (center_freq >= 5500 && center_freq <= 5700);
return (center_freq >= 5260 && center_freq <= 5700);
}
@@ -306,7 +310,7 @@ __ath_reg_apply_beaconing_flags(struct wiphy *wiphy,
enum nl80211_reg_initiator initiator,
struct ieee80211_channel *ch)
{
- if (ath_is_radar_freq(ch->center_freq) ||
+ if (ath_is_radar_freq(ch->center_freq, reg) ||
(ch->flags & IEEE80211_CHAN_RADAR))
return;
@@ -395,8 +399,9 @@ ath_reg_apply_ir_flags(struct wiphy *wiphy,
}
}
-/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */
-static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
+/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */
+static void ath_reg_apply_radar_flags(struct wiphy *wiphy,
+ struct ath_regulatory *reg)
{
struct ieee80211_supported_band *sband;
struct ieee80211_channel *ch;
@@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
for (i = 0; i < sband->n_channels; i++) {
ch = &sband->channels[i];
- if (!ath_is_radar_freq(ch->center_freq))
+ if (!ath_is_radar_freq(ch->center_freq, reg))
continue;
/* We always enable radar detection/DFS on this
* frequency range. Additionally we also apply on
@@ -505,7 +510,7 @@ void ath_reg_notifier_apply(struct wiphy *wiphy,
struct ath_common *common = container_of(reg, struct ath_common,
regulatory);
/* We always apply this */
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);
/*
* This would happen when we have sent a custom regulatory request
@@ -653,7 +658,7 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
}
wiphy_apply_custom_regulatory(wiphy, regd);
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);
ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg);
return 0;
}
--
2.14.1
[PATCH AUTOSEL for 3.18 13/53] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs
From: Hans de Goede [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ] When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction flags get filled with the trigger type from the irq_data: if (!(new->flags & IRQF_TRIGGER_MASK)) new->flags |= irqd_get_trigger_type(&desc->irq_data); On the first setup_irq() the trigger type in irq_data is NONE when the above code executes, then the irq is started up for the first time and then the actual trigger type gets established, but that's too late to fix up new->flags. When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE its irqaction's triggertype gets set to the actual trigger type and the following check fails: if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK)) Resulting in the request_irq failing with -EBUSY even though both users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE Fix this by comparing the new irqaction's trigger type to the trigger type stored in the irq_data which correctly reflects the actual trigger type being used for the irq. Suggested-by: Thomas Gleixner Signed-off-by: Hans de Goede Acked-by: Marc Zyngier Link: http://lkml.kernel.org/r/20170415100831.17073-1-hdego...@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin --- kernel/irq/manage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index e7ef539c56d9..5f23a04789db 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1058,8 +1058,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new) * set the trigger type must match. Also all must * agree on ONESHOT. */ + unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data); + if (!((old->flags & new->flags) & IRQF_SHARED) || - ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) || + (oldtype != (new->flags & IRQF_TRIGGER_MASK)) || ((old->flags ^ new->flags) & IRQF_ONESHOT)) goto mismatch; -- 2.14.1
[PATCH AUTOSEL for 3.18 17/53] spi: dw: Disable clock after unregistering the host
From: Marek Vasut
[ Upstream commit 400c18e3dc86e04ef5afec9b86a8586ca629b9e9 ]
The dw_mmio driver disables the block clock before unregistering
the host. The code unregistering the host may access the SPI block
registers. If register access happens with block clock disabled,
this may lead to a bus hang. Disable the clock after unregistering
the host to prevent such situation.
This bug was observed on Altera Cyclone V SoC.
Signed-off-by: Marek Vasut
Cc: Andy Shevchenko
Cc: Mark Brown
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-dw-mmio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 21ce0e36fa00..d3b6501db535 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -118,8 +118,8 @@ static int dw_spi_mmio_remove(struct platform_device *pdev)
{
struct dw_spi_mmio *dwsmmio = platform_get_drvdata(pdev);
- clk_disable_unprepare(dwsmmio->clk);
dw_spi_remove_host(&dwsmmio->dws);
+ clk_disable_unprepare(dwsmmio->clk);
return 0;
}
--
2.14.1
[PATCH AUTOSEL for 3.18 21/53] tcp: remove poll() flakes with FastOpen
From: Eric Dumazet
[ Upstream commit 0f9fa831aecfc297b7b45d4f046759bcefcf87f0 ]
When using TCP FastOpen for an active session, we send one wakeup event
from tcp_finish_connect(), right before the data eventually contained in
the received SYNACK is queued to sk->sk_receive_queue.
This means that depending on machine load or luck, poll() users
might receive POLLOUT events instead of POLLIN|POLLOUT
To fix this, we need to move the call to sk->sk_state_change()
after the (optional) call to tcp_rcv_fastopen_synack()
Signed-off-by: Eric Dumazet
Acked-by: Yuchung Cheng
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/ipv4/tcp_input.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index f705356f538b..8d61c870643e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5322,10 +5322,6 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff
*skb)
else
tp->pred_flags = 0;
- if (!sock_flag(sk, SOCK_DEAD)) {
- sk->sk_state_change(sk);
- sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
- }
}
static bool tcp_rcv_fastopen_synack(struct sock *sk, struct sk_buff *synack,
@@ -5380,6 +5376,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk,
struct sk_buff *skb,
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_fastopen_cookie foc = { .len = -1 };
int saved_clamp = tp->rx_opt.mss_clamp;
+ bool fastopen_fail;
tcp_parse_options(skb, &tp->rx_opt, 0, &foc);
if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
@@ -5482,10 +5479,15 @@ static int tcp_rcv_synsent_state_process(struct sock
*sk, struct sk_buff *skb,
tcp_finish_connect(sk, skb);
- if ((tp->syn_fastopen || tp->syn_data) &&
- tcp_rcv_fastopen_synack(sk, skb, &foc))
- return -1;
+ fastopen_fail = (tp->syn_fastopen || tp->syn_data) &&
+ tcp_rcv_fastopen_synack(sk, skb, &foc);
+ if (!sock_flag(sk, SOCK_DEAD)) {
+ sk->sk_state_change(sk);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
+ }
+ if (fastopen_fail)
+ return -1;
if (sk->sk_write_pending ||
icsk->icsk_accept_queue.rskq_defer_accept ||
icsk->icsk_ack.pingpong) {
--
2.14.1
[PATCH AUTOSEL for 3.18 16/53] [media] media/dvb-core: Race condition when writing to CAM
From: Jasmin J
[ Upstream commit e7080d4471d805d921a9ea21b32f911a91e248cb ]
It started with a sporadic message in syslog: "CAM tried to send a
buffer larger than the ecount size" This message is not the fault
itself, but a consecutive fault, after a read error from the CAM. This
happens only on several CAMs, several hardware, and of course sporadic.
It is a consecutive fault, if the last read from the CAM did fail. I
guess this will not happen on all CAMs, but at least it did on mine.
There was a write error to the CAM and during the re-initialization
procedure, the CAM finished the last read, although it got a RS.
The write error to the CAM happened because a race condition between HC
write, checking DA and FR.
This patch added an additional check for DA(RE), just after checking FR.
It is important to read the CAMs status register again, to give the CAM
the necessary time for a proper reaction to HC. Please note the
description within the source code (patch below).
[mche...@s-opensource.com: make checkpatch happy]
Signed-off-by: Jasmin jessich
Tested-by: Ralph Metzler
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/dvb-core/dvb_ca_en50221.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c
b/drivers/media/dvb-core/dvb_ca_en50221.c
index 0aac3096728e..051bdfac6a1d 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -749,6 +749,29 @@ static int dvb_ca_en50221_write_data(struct dvb_ca_private
*ca, int slot, u8 * b
goto exit;
}
+ /*
+* It may need some time for the CAM to settle down, or there might
+* be a race condition between the CAM, writing HC and our last
+* check for DA. This happens, if the CAM asserts DA, just after
+* checking DA before we are setting HC. In this case it might be
+* a bug in the CAM to keep the FR bit, the lower layer/HW
+* communication requires a longer timeout or the CAM needs more
+* time internally. But this happens in reality!
+* We need to read the status from the HW again and do the same
+* we did for the previous check for DA
+*/
+ status = ca->pub->read_cam_control(ca->pub, slot, CTRLIF_STATUS);
+ if (status < 0)
+ goto exit;
+
+ if (status & (STATUSREG_DA | STATUSREG_RE)) {
+ if (status & STATUSREG_DA)
+ dvb_ca_en50221_thread_wakeup(ca);
+
+ status = -EAGAIN;
+ goto exit;
+ }
+
/* send the amount of data */
if ((status = ca->pub->write_cam_control(ca->pub, slot,
CTRLIF_SIZE_HIGH, bytes_write >> 8)) != 0)
goto exit;
--
2.14.1
[PATCH AUTOSEL for 3.18 20/53] KVM: PPC: Book3S PR: Exit KVM on failed mapping
From: Alexey Kardashevskiy
[ Upstream commit bd9166ffe624000140fc6b606b256df01fc0d060 ]
At the moment kvmppc_mmu_map_page() returns -1 if
mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler
resumes the guest and it faults on the same address again.
This adds distinction to kvmppc_mmu_map_page() to return -EIO if
mmu_hash_ops.hpte_insert() failed for a reason other than full pteg.
At the moment only pSeries_lpar_hpte_insert() returns -2 if
plpar_pte_enter() failed with a code other than H_PTEG_FULL.
Other mmu_hash_ops.hpte_insert() instances can only fail with
-1 "full pteg".
With this change, if PR KVM fails to update HPT, it can signal
the userspace about this instead of returning to guest and having
the very same page fault over and over again.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Signed-off-by: Paul Mackerras
Signed-off-by: Sasha Levin
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 5 -
arch/powerpc/kvm/book3s_pr.c | 6 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index b982d925c710..c74c9c4134b5 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -176,12 +176,15 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct
kvmppc_pte *orig_pte,
ret = ppc_md.hpte_insert(hpteg, vpn, hpaddr, rflags, vflags,
hpsize, hpsize, MMU_SEGSIZE_256M);
- if (ret < 0) {
+ if (ret == -1) {
/* If we couldn't map a primary PTE, try a secondary */
hash = ~hash;
vflags ^= HPTE_V_SECONDARY;
attempt++;
goto map_again;
+ } else if (ret < 0) {
+ r = -EIO;
+ goto out_unlock;
} else {
trace_kvm_book3s_64_mmu_map(rflags, hpteg,
vpn, hpaddr, orig_pte);
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index cf2eb16846d1..db549f2ae98f 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -625,7 +625,11 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct
kvm_vcpu *vcpu,
kvmppc_mmu_unmap_page(vcpu, &pte);
}
/* The guest's PTE is not mapped yet. Map on the host */
- kvmppc_mmu_map_page(vcpu, &pte, iswrite);
+ if (kvmppc_mmu_map_page(vcpu, &pte, iswrite) == -EIO) {
+ /* Exit KVM if mapping failed */
+ run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ return RESUME_HOST;
+ }
if (data)
vcpu->stat.sp_storage++;
else if (vcpu->arch.mmu.is_dcbz32(vcpu) &&
--
2.14.1
[PATCH AUTOSEL for 3.18 32/53] Btrfs: send, fix file hole not being preserved due to inline extent
From: Filipe Manana
[ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ]
Normally we don't have inline extents followed by regular extents, but
there's currently at least one harmless case where this happens. For
example, when the page size is 4Kb and compression is enabled:
$ mkfs.btrfs -f /dev/sdb
$ mount -o compress /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
$ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
In this case we get a compressed inline extent, representing 4Kb of
data, followed by a hole extent and then a regular data extent. The
inline extent was not expanded/converted to a regular extent exactly
because it represents 4Kb of data. This does not cause any apparent
problem (such as the issue solved by commit e1699d2d7bf6
("btrfs: add missing memset while reading compressed inline extents"))
except trigger an unexpected case in the incremental send code path
that makes us issue an operation to write a hole when it's not needed,
resulting in more writes at the receiver and wasting space at the
receiver.
So teach the incremental send code to deal with this particular case.
The issue can be currently triggered by running fstests btrfs/137 with
compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
Signed-off-by: Filipe Manana
Reviewed-by: Liu Bo
Signed-off-by: Sasha Levin
---
fs/btrfs/send.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index fc2472ef5011..a7c4e2f205dd 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -4663,13 +4663,19 @@ static int is_extent_unchanged(struct send_ctx *sctx,
while (key.offset < ekey->offset + left_len) {
ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item);
right_type = btrfs_file_extent_type(eb, ei);
- if (right_type != BTRFS_FILE_EXTENT_REG) {
+ if (right_type != BTRFS_FILE_EXTENT_REG &&
+ right_type != BTRFS_FILE_EXTENT_INLINE) {
ret = 0;
goto out;
}
right_disknr = btrfs_file_extent_disk_bytenr(eb, ei);
- right_len = btrfs_file_extent_num_bytes(eb, ei);
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ right_len = btrfs_file_extent_inline_len(eb, slot, ei);
+ right_len = PAGE_ALIGN(right_len);
+ } else {
+ right_len = btrfs_file_extent_num_bytes(eb, ei);
+ }
right_offset = btrfs_file_extent_offset(eb, ei);
right_gen = btrfs_file_extent_generation(eb, ei);
@@ -4683,6 +4689,19 @@ static int is_extent_unchanged(struct send_ctx *sctx,
goto out;
}
+ /*
+* We just wanted to see if when we have an inline extent, what
+* follows it is a regular extent (wanted to check the above
+* condition for inline extents too). This should normally not
+* happen but it's possible for example when we have an inline
+* compressed extent representing data with a size matching
+* the page size (currently the same as sector size).
+*/
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ ret = 0;
+ goto out;
+ }
+
left_offset_fixed = left_offset;
if (key.offset < ekey->offset) {
/* Fix the right offset for 2a and 7. */
--
2.14.1
[PATCH AUTOSEL for 3.18 40/53] ia64: fix module loading for gcc-5.4
From: Sergei Trofimovich
[ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ]
Starting from gcc-5.4+ gcc generates MLX instructions in more cases to
refer local symbols:
https://gcc.gnu.org/PR60465
That caused ia64 module loader to choke on such instructions:
fuse: invalid slot number 1 for IMM64
The Linux kernel used to handle only case where relocation pointed to
slot=2 instruction in the bundle. That limitation was fixed in linux by
commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler")
See
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433
This change lifts the slot=2 restriction from the kernel module loader.
Tested on 'fuse' and 'btrfs' kernel modules.
Cc: Markus Elfring
Cc: H J Lu
Cc: Fenghua Yu
Cc: Andrew Morton
Bug: https://bugs.gentoo.org/601014
Tested-by: Émeric MASCHINO
Signed-off-by: Sergei Trofimovich
Signed-off-by: Tony Luck
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/ia64/kernel/module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/module.c b/arch/ia64/kernel/module.c
index 24603be24c14..67f09b93dab7 100644
--- a/arch/ia64/kernel/module.c
+++ b/arch/ia64/kernel/module.c
@@ -153,7 +153,7 @@ slot (const struct insn *insn)
static int
apply_imm64 (struct module *mod, struct insn *insn, uint64_t val)
{
- if (slot(insn) != 2) {
+ if (slot(insn) != 1 && slot(insn) != 2) {
printk(KERN_ERR "%s: invalid slot number %d for IMM64\n",
mod->name, slot(insn));
return 0;
@@ -165,7 +165,7 @@ apply_imm64 (struct module *mod, struct insn *insn,
uint64_t val)
static int
apply_imm60 (struct module *mod, struct insn *insn, uint64_t val)
{
- if (slot(insn) != 2) {
+ if (slot(insn) != 1 && slot(insn) != 2) {
printk(KERN_ERR "%s: invalid slot number %d for IMM60\n",
mod->name, slot(insn));
return 0;
--
2.14.1
[PATCH AUTOSEL for 3.18 42/53] sm501fb: don't return zero on failure path in sm501fb_start()
From: Alexey Khoroshilov
[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Cc: Tomi Valkeinen
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/sm501fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 9e74e8fbe074..aa3fdb89043c 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1600,6 +1600,7 @@ static int sm501fb_start(struct sm501fb_info *info,
info->fbmem = ioremap(res->start, resource_size(res));
if (info->fbmem == NULL) {
dev_err(dev, "cannot remap framebuffer\n");
+ ret = -ENXIO;
goto err_mem_res;
}
--
2.14.1
[PATCH AUTOSEL for 3.18 36/53] ipmi/watchdog: fix wdog hang on panic waiting for ipmi response
From: Robert Lippert
[ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]
Commit c49c097610fe ("ipmi: Don't call receive handler in the
panic context") means that the panic_recv_free is not called during a
panic and the atomic count does not drop to 0.
Fix this by only expecting one decrement of the atomic variable
which comes from panic_smi_free.
Signed-off-by: Robert Lippert
Signed-off-by: Corey Minyard
Signed-off-by: Sasha Levin
---
drivers/char/ipmi/ipmi_watchdog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index f335fcee09af..0109d3fb5fbc 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -509,7 +509,7 @@ static void panic_halt_ipmi_heartbeat(void)
msg.cmd = IPMI_WDOG_RESET_TIMER;
msg.data = NULL;
msg.data_len = 0;
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = ipmi_request_supply_msgs(watchdog_user,
(struct ipmi_addr *) &addr,
0,
@@ -519,7 +519,7 @@ static void panic_halt_ipmi_heartbeat(void)
&panic_halt_heartbeat_recv_msg,
1);
if (rv)
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
}
static struct ipmi_smi_msg panic_halt_smi_msg = {
@@ -543,12 +543,12 @@ static void panic_halt_ipmi_set_timeout(void)
/* Wait for the messages to be free. */
while (atomic_read(&panic_done_count) != 0)
ipmi_poll_interface(watchdog_user);
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = i_ipmi_set_timeout(&panic_halt_smi_msg,
&panic_halt_recv_msg,
&send_heartbeat_now);
if (rv) {
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
printk(KERN_WARNING PFX
"Unable to extend the watchdog timeout.");
} else {
--
2.14.1
[PATCH AUTOSEL for 3.18 41/53] video: fbdev: udlfb: Fix buffer on stack
From: Maksim Salau
[ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]
Allocate buffers on HEAP instead of STACK for local array
that is to be sent using usb_control_msg().
Signed-off-by: Maksim Salau
Cc: Bernie Thompson
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/udlfb.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index ef7d23bb2e28..868cba997585 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1490,15 +1490,25 @@ static struct device_attribute fb_device_attrs[] = {
static int dlfb_select_std_channel(struct dlfb_data *dev)
{
int ret;
- u8 set_def_chn[] = { 0x57, 0xCD, 0xDC, 0xA7,
+ void *buf;
+ static const u8 set_def_chn[] = {
+ 0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
0x60, 0xFE, 0xC6, 0x97,
0x16, 0x3D, 0x47, 0xF2 };
+ buf = kmemdup(set_def_chn, sizeof(set_def_chn), GFP_KERNEL);
+
+ if (!buf)
+ return -ENOMEM;
+
ret = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
NR_USB_REQUEST_CHANNEL,
(USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
- set_def_chn, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+ buf, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+
+ kfree(buf);
+
return ret;
}
--
2.14.1
