Re: [PATCH v7 2/6] mfd: syscon: add a DT property to set value width
Lee, Arnd,
I had to make changes in this patch to address Rob's comments.
reg-io-width is now in bytes while bus-width was a value in bits. Could
you please review this patch ?
Thanks,
Damien
On Mon, Nov 30, 2015 at 01:00:15PM -0600, Rob Herring wrote:
> On Mon, Nov 30, 2015 at 10:59:47AM -0500, Damien Riegel wrote:
> > Currently syscon has a fixed configuration of 32 bits for register and
> > values widths. In some cases, it would be desirable to be able to
> > customize the value width.
> >
> > For example, certain boards (like the ones manufactured by Technologic
> > Systems) have a FPGA that is memory-mapped, but its registers are only
> > 16-bit wide.
> >
> > This patch adds an optional "reg-io-width" DT binding for syscon that
> > allows to change the width for the data bus (i.e. val_bits). If this
> > property is provided, it will also set the register stride to
> > reg-io-width's value. If not provided, the default configuration is
> > used.
> >
> > Signed-off-by: Damien Riegel
>
> Acked-by: Rob Herring
>
> > ---
> > Documentation/devicetree/bindings/mfd/syscon.txt | 4
> > drivers/mfd/syscon.c | 13 +
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> > b/Documentation/devicetree/bindings/mfd/syscon.txt
> > index fe8150b..408f768 100644
> > --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> > @@ -13,6 +13,10 @@ Required properties:
> > - compatible: Should contain "syscon".
> > - reg: the register region can be accessed from syscon
> >
> > +Optional property:
> > +- reg-io-width: the size (in bytes) of the IO accesses that should be
> > + performed on the device.
> > +
> > Examples:
> > gpr: iomuxc-gpr@020e {
> > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> > index 176bf0f..b7aabee 100644
> > --- a/drivers/mfd/syscon.c
> > +++ b/drivers/mfd/syscon.c
> > @@ -47,6 +47,7 @@ static struct syscon *of_syscon_register(struct
> > device_node *np)
> > struct syscon *syscon;
> > struct regmap *regmap;
> > void __iomem *base;
> > + u32 reg_io_width;
> > int ret;
> > struct regmap_config syscon_config = syscon_regmap_config;
> >
> > @@ -69,6 +70,18 @@ static struct syscon *of_syscon_register(struct
> > device_node *np)
> > else if (of_property_read_bool(np, "little-endian"))
> > syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
> >
> > + /*
> > +* search for reg-io-width property in DT. If it is not provided,
> > +* default to 4 bytes. regmap_init_mmio will return an error if values
> > +* are invalid so there is no need to check them here.
> > +*/
> > + ret = of_property_read_u32(np, "reg-io-width", _io_width);
> > + if (ret)
> > + reg_io_width = 4;
> > +
> > + syscon_config.reg_stride = reg_io_width;
> > + syscon_config.val_bits = reg_io_width * 8;
> > +
> > regmap = regmap_init_mmio(NULL, base, _config);
> > if (IS_ERR(regmap)) {
> > pr_err("regmap init failed\n");
> > --
> > 2.5.0
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 7/7] sparc64: mm/gup: add gup trace points
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Signed-off-by: Yang Shi
---
The context depends on the below patch:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1028752.html
arch/sparc/mm/gup.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/sparc/mm/gup.c b/arch/sparc/mm/gup.c
index cf4fb47..6dcfc4d 100644
--- a/arch/sparc/mm/gup.c
+++ b/arch/sparc/mm/gup.c
@@ -10,6 +10,10 @@
#include
#include
#include
+
+#define CREATE_TRACE_POINTS
+#include
+
#include
/*
@@ -177,6 +181,8 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
(void __user *)start, len)))
return 0;
+ trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
+
local_irq_save(flags);
pgdp = pgd_offset(mm, addr);
do {
@@ -209,6 +215,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
if (end < start)
goto slow_irqon;
+ trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
+
/*
* XXX: batch / limit 'nr', to avoid large irq off latency
* needs some instrumenting to determine the common sizes used by
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 29/86] ext4, jbd2: ensure entering into panic after recording an error in superblock
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Daeho Jeong
commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.
If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option. But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.
Task ATask B
ext4_handle_error()
-> jbd2_journal_abort()
-> __journal_abort_soft()
-> __jbd2_journal_abort_hard()
| -> journal->j_flags |= JBD2_ABORT;
|
| __ext4_abort()
| -> jbd2_journal_abort()
| | -> __journal_abort_soft()
| | -> if (journal->j_flags & JBD2_ABORT)
| | return;
| -> panic()
|
-> jbd2_journal_update_sb_errno()
Tested-by: Hobin Woo
Signed-off-by: Daeho Jeong
Signed-off-by: Theodore Ts'o
Signed-off-by: Kamal Mostafa
---
fs/ext4/super.c | 12 ++--
fs/jbd2/journal.c| 6 +-
include/linux/jbd2.h | 1 +
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c261beb..3b31342 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -404,9 +404,13 @@ static void ext4_handle_error(struct super_block *sb)
smp_wmb();
sb->s_flags |= MS_RDONLY;
}
- if (test_opt(sb, ERRORS_PANIC))
+ if (test_opt(sb, ERRORS_PANIC)) {
+ if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+ return;
panic("EXT4-fs (device %s): panic forced after error\n",
sb->s_id);
+ }
}
#define ext4_error_ratelimit(sb) \
@@ -595,8 +599,12 @@ void __ext4_abort(struct super_block *sb, const char
*function,
jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
save_error_info(sb, function, line);
}
- if (test_opt(sb, ERRORS_PANIC))
+ if (test_opt(sb, ERRORS_PANIC)) {
+ if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+ return;
panic("EXT4-fs panic from previous error\n");
+ }
}
void __ext4_msg(struct super_block *sb,
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 3b607a8..ef5f39a 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2088,8 +2088,12 @@ static void __journal_abort_soft (journal_t *journal,
int errno)
__jbd2_journal_abort_hard(journal);
- if (errno)
+ if (errno) {
jbd2_journal_update_sb_errno(journal);
+ write_lock(>j_state_lock);
+ journal->j_flags |= JBD2_REC_ERR;
+ write_unlock(>j_state_lock);
+ }
}
/**
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 385593d..e137e96 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1007,6 +1007,7 @@ struct journal_s
#define JBD2_ABORT_ON_SYNCDATA_ERR 0x040 /* Abort the journal on file
* data write error in ordered
* mode */
+#define JBD2_REC_ERR 0x080 /* The errno in the sb has been recorded */
/*
* Function declarations for the journaling transaction and buffer
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
On 11/18/2015 02:49 PM, Matwey V. Kornilov wrote: > 2015-11-18 22:39 GMT+03:00 Matwey V. Kornilov : >> 2015-11-18 21:33 GMT+03:00 Peter Hurley : >>> On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote: 2015-11-16 22:18 GMT+03:00 Peter Hurley : > On 11/14/2015 10:25 AM, One Thousand Gnomes wrote: [...] >> It's also not "easy to drop". If it ever goes in we are stuck with a >> pointless impossible to correctly set flag for all eternity. >> >> Please explain the correct setting for this flag when a device driver >> uses hardware or software or a mix according to what the silicon is >> capable of and what values are requested ? How will an application use >> the >> flag meaningfully. Please explain what will happen if someone discovers a >> silicon bug and in a future 4.x release turns an implementation from >> hardware to software - will they have to lie about the flag to avoid >> breaking their application code - that strikes me as a bad thing. > > The existing driver behavior is already significantly variant and needs > to be converged, which shouldn't be too difficult. Here's a quick summary: > > mcfuart ignores delay values, delays unsupported > imx clamps delay values to 0, delays unsupported > atmel only delay_rts_after_send used; delay_rts_before_send > does nothing > 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs > omap-serial*software emulation (but tx empty polling not reqd) > lpc18xx-uartclamps delay_rts_before_send to 0, unsupported > clamps delay_rts_after_send to max h/w value > max310x returns -ERANGE if either delay value > h/w support (15 > msecs) > sc16is7xx* returns -EINVAL if delay_rts_after_send is set > crisv10*clamps delay_rts_before_send to 1000 msecs > ignores delays_rts_after_send (after dma is delayed by 2 > * chars) > * implements delay(s) in software > > The omap-serial emulation should not have been merged in its current form. > > IMO the proper driver behavior should be clamp to h/w limit so an > application > can determine the maximum delay supported. If a delay is unsupported, it > should > be clamped to 0. The application should check the RS485 settings returned > by > TIOCSRS485 to determine how the driver set them. > [ Documentation/serial/serial-rs485.txt should suggest/model this action ] But the similar could be true for minimal supported delay. If user requires delay which is less than lower bound, the delay is raised to the lower bound. If user requires delay which is greater than upper bound, the delay is set to the upper bound. Then software implementation could use (tx fifo size / baudrate) as lower bound for delay_after_send. >>> >>> From the application point-of-view (really the only relevant semantics), >>> delay_dts_after_send refers to the number of milliseconds to delay the >>> toggle of RTS after the last bit has been _transmitted_. Is there consensus then about what the semantics of unsupported RS485 delay values are? I (or someone else) can trivially add the documentation and fixes to the existing in-tree drivers. >>> A couple of possibilities for improving the emulation are: >>> 1) Optionally using an HR timer for sub-jiffy turnaround. >>> 2) Only supporting 8250-based hardware that can be set to interrupt when >>>both tx fifo and transmitter shift register are empty. >> >> This is to support the RS485 API with already exists in omap_serrial, >> but not in 8250_omap. And OMAP does not support tx line interrupt in >> UART mode. So the latter is not an option. > > Oh, I am sorry, it does support. There is "Supplementary Control > Register" described in 19.5.1.39 For the moment then, can we add a UART_CAP_SW485 (not exposed to userspace) that enables this algorithm only for h/w that supports a both-empty interrupt mode. The probe or driver (ala 8250_omap) would opt-in and configure the h/w much like the omap-serial driver does now (with the SCR register). Does that seem like an acceptable compromise? Regards, Peter Hurley PS - I still need to review this series for how the timer logic works esp. wrt teardown. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 33/86] Bluetooth: ath3k: Add new AR3012 0930:021c id
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Dmitry Tunin
commit cd355ff071cd37e7197eccf9216770b2b29369f7 upstream.
This adapter works with the existing linux-firmware.
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0930 ProdID=021c Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1502781
Signed-off-by: Dmitry Tunin
Signed-off-by: Marcel Holtmann
Signed-off-by: Kamal Mostafa
---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 00aa6d6..146d3dc 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -91,6 +91,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x300f) },
{ USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
+ { USB_DEVICE(0x0930, 0x021c) },
{ USB_DEVICE(0x0930, 0x0220) },
{ USB_DEVICE(0x0930, 0x0227) },
{ USB_DEVICE(0x0b05, 0x17d0) },
@@ -149,6 +150,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a363f7f..7e13b54 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -169,6 +169,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 32/86] Bluetooth: hidp: fix device disconnect on idle timeout
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: David Herrmann
commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.
The HIDP specs define an idle-timeout which automatically disconnects a
device. This has always been implemented in the HIDP layer and forced a
synchronous shutdown of the hidp-scheduler. This works just fine, but
lacks a forced disconnect on the underlying l2cap channels. This has been
broken since:
commit 5205185d461d5902325e457ca80bd421127b7308
Author: David Herrmann
Date: Sat Apr 6 20:28:47 2013 +0200
Bluetooth: hidp: remove old session-management
The old session-management always forced an l2cap error on the ctrl/intr
channels when shutting down. The new session-management skips this, as we
don't want to enforce channel policy on the caller. In other words, if
user-space removes an HIDP device, the underlying channels (which are
*owned* and *referenced* by user-space) are still left active. User-space
needs to call shutdown(2) or close(2) to release them.
Unfortunately, this does not work with idle-timeouts. There is no way to
signal user-space that the HIDP layer has been stopped. The API simply
does not support any event-passing except for poll(2). Hence, we restore
old behavior and force EUNATCH on the sockets if the HIDP layer is
disconnected due to idle-timeouts (behavior of explicit disconnects
remains unmodified). User-space can still call
getsockopt(..., SO_ERROR, ...)
..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
still be re-used (which nobody does so far, though). Therefore, the API
still supports the new behavior, but with this patch it's also compatible
to the old implicit channel shutdown.
Reported-by: Mark Haun
Reported-by: Luiz Augusto von Dentz
Signed-off-by: David Herrmann
Signed-off-by: Marcel Holtmann
Signed-off-by: Kamal Mostafa
---
net/bluetooth/hidp/core.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 292e619..f6ebe25 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -415,6 +415,20 @@ static void hidp_idle_timeout(unsigned long arg)
{
struct hidp_session *session = (struct hidp_session *) arg;
+ /* The HIDP user-space API only contains calls to add and remove
+* devices. There is no way to forward events of any kind. Therefore,
+* we have to forcefully disconnect a device on idle-timeouts. This is
+* unfortunate and weird API design, but it is spec-compliant and
+* required for backwards-compatibility. Hence, on idle-timeout, we
+* signal driver-detach events, so poll() will be woken up with an
+* error-condition on both sockets.
+*/
+
+ session->intr_sock->sk->sk_err = EUNATCH;
+ session->ctrl_sock->sk->sk_err = EUNATCH;
+ wake_up_interruptible(sk_sleep(session->intr_sock->sk));
+ wake_up_interruptible(sk_sleep(session->ctrl_sock->sk));
+
hidp_session_terminate(session);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 34/86] Bluetooth: ath3k: Add support of AR3012 0cf3:817b device
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Dmitry Tunin
commit 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 upstream.
T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=817b Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1506615
Signed-off-by: Dmitry Tunin
Signed-off-by: Marcel Holtmann
Signed-off-by: Kamal Mostafa
---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 146d3dc..120a5fb 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -103,6 +103,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0CF3, 0x311F) },
{ USB_DEVICE(0x0cf3, 0x3121) },
{ USB_DEVICE(0x0CF3, 0x817a) },
+ { USB_DEVICE(0x0CF3, 0x817b) },
{ USB_DEVICE(0x0cf3, 0xe003) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0CF3, 0xE005) },
@@ -163,6 +164,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0CF3, 0x817a), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0CF3, 0x817b), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7e13b54..fe2fbeb 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -181,6 +181,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0cf3, 0x311f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0x817b), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 38/86] ALSA: hda/realtek - Dell XPS one ALC3260 speaker no sound after resume back
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Kailang Yang
commit 6ed1131fe196ad7ffc13acc1a1eadc08a1db0303 upstream.
This machine had I2S codec for speaker output.
It need to refill the I2S codec initial verb after resume back.
Signed-off-by: Kailang Yang
Reported-and-tested-by: George Gugulea
Signed-off-by: Takashi Iwai
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
sound/pci/hda/patch_realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e8fda21..368b2bb 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4020,6 +4020,7 @@ enum {
ALC269_FIXUP_THINKPAD_ACPI,
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC255_FIXUP_HEADSET_MODE,
+ ALC275_FIXUP_DELL_XPS,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -4394,6 +4395,17 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_headset_mode_alc255,
},
+ [ALC275_FIXUP_DELL_XPS] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Enables internal speaker */
+ {0x20, AC_VERB_SET_COEF_INDEX, 0x1f},
+ {0x20, AC_VERB_SET_PROC_COEF, 0x00c0},
+ {0x20, AC_VERB_SET_COEF_INDEX, 0x30},
+ {0x20, AC_VERB_SET_PROC_COEF, 0x00b1},
+ {}
+ }
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -4408,6 +4420,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
+ SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell",
ALC269_FIXUP_DELL2_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x05be, "Dell",
ALC269_FIXUP_DELL2_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x05c4, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 40/86] MAINTAINERS: Add public mailing list for ARC
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Vineet Gupta commit 9acdc911b55569145034b01075adf658891afbd2 upstream. Signed-off-by: Vineet Gupta Signed-off-by: Kamal Mostafa --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6a6e4ac..511bf41 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8301,6 +8301,7 @@ F:include/linux/swiotlb.h SYNOPSYS ARC ARCHITECTURE M: Vineet Gupta +L: linux-snps-...@lists.infraded.org S: Supported F: arch/arc/ F: Documentation/devicetree/bindings/arc/ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 11/86] qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
[ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ]
The lt4112 is a HP branded Huawei me906e modem. Like other Huawei
modems, it does not have a fixed interface to function mapping.
Instead it uses a Huawei specific scheme: functions are mapped by
subclass and protocol.
However, the HP vendor ID is used for modems from many different
manufacturers using different schemes, so we cannot apply a generic
vendor rule like we do for the Huawei vendor ID.
Replace the previous lt4112 entry pointing to an arbitrary interface
number with a device specific subclass + protocol match.
Reported-and-tested-by: Muri Nicanor
Tested-by: Martin Hauke
Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G
Modem")
Signed-off-by: Bjørn Mork
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
drivers/net/usb/qmi_wwan.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8cd9765..7bd1716 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -528,6 +528,10 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info= (unsigned long)_wwan_info,
},
+ { /* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x581d,
USB_CLASS_VENDOR_SPEC, 1, 7),
+ .driver_info = (unsigned long)_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x0408, 0xea42, 4)},/* Yota / Megafon M100-1 */
@@ -767,7 +771,6 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+
(42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},/* Dell Wireless 5808 Gobi(TM)
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},/* Dell Wireless 5808e Gobi(TM)
4G LTE Mobile Broadband Card */
- {QMI_FIXED_INTF(0x03f0, 0x581d, 4)},/* HP lt4112 LTE/HSPA+ Gobi 4G
Module (Huawei me906e) */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 37/86] ACPI: Use correct IRQ when uninstalling ACPI interrupt handler
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Chen Yu
commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.
Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.
Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.
Acked-by: Lv Zheng
Signed-off-by: Chen Yu
Signed-off-by: Rafael J. Wysocki
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
drivers/acpi/osl.c | 9 ++---
include/linux/acpi.h | 6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index bd2e23e..bd79c6e 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -87,6 +87,7 @@ static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
static struct workqueue_struct *kacpi_notify_wq;
static struct workqueue_struct *kacpi_hotplug_wq;
+unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
/*
* This list of permanent mappings is for memory that may be accessed from
@@ -818,17 +819,19 @@ acpi_os_install_interrupt_handler(u32 gsi,
acpi_osd_handler handler,
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
}
+ acpi_sci_irq = irq;
return AE_OK;
}
-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler)
+acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
{
- if (irq != acpi_gbl_FADT.sci_interrupt)
+ if (gsi != acpi_gbl_FADT.sci_interrupt || !acpi_sci_irq_valid())
return AE_BAD_PARAMETER;
- free_irq(irq, acpi_irq);
+ free_irq(acpi_sci_irq, acpi_irq);
acpi_irq_handler = NULL;
+ acpi_sci_irq = INVALID_ACPI_IRQ;
return AE_OK;
}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d9099b1..f264bca 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -139,6 +139,12 @@ int acpi_unregister_ioapic(acpi_handle handle, u32
gsi_base);
void acpi_irq_stats_init(void);
extern u32 acpi_irq_handled;
extern u32 acpi_irq_not_handled;
+extern unsigned int acpi_sci_irq;
+#define INVALID_ACPI_IRQ ((unsigned)-1)
+static inline bool acpi_sci_irq_valid(void)
+{
+ return acpi_sci_irq != INVALID_ACPI_IRQ;
+}
extern int sbf_port;
extern unsigned long acpi_realmode_flags;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 35/86] spi: atmel: Fix DMA-setup for transfers with more than 8 bits per word
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: David Mosberger-Tang commit 06515f83908d038d9e12ffa3dcca27a1b67f2de0 upstream. The DMA-slave configuration depends on the whether <= 8 or > 8 bits are transferred per word, so we need to call atmel_spi_dma_slave_config() with the correct value. Signed-off-by: David Mosberger Signed-off-by: Nicolas Ferre Signed-off-by: Mark Brown Signed-off-by: Kamal Mostafa --- drivers/spi/spi-atmel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 273db0b..3703358 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -606,7 +606,8 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master, *plen = len; - if (atmel_spi_dma_slave_config(as, _config, 8)) + if (atmel_spi_dma_slave_config(as, _config, + xfer->bits_per_word)) goto err_exit; /* Send both scatterlists */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 31/86] [media] media: vb2 dma-contig: Fully cache synchronise buffers in prepare and finish
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Tiffany Lin
commit d9a985883fa32453d099d6293188c11d75cef1fa upstream.
In videobuf2 dma-contig memory type the prepare and finish ops, instead of
passing the number of entries in the original scatterlist as the "nents"
parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), the value
returned by dma_map_sg() was used. Albeit this has been suggested in
comments of some implementations (which have since been corrected), this
is wrong.
Fixes: 199d101efdba ("v4l: vb2-dma-contig: add prepare/finish to dma-contig
allocator")
Signed-off-by: Tiffany Lin
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Kamal Mostafa
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 33d3871d..63aeac9 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -117,7 +117,8 @@ static void vb2_dc_prepare(void *buf_priv)
if (!sgt || buf->db_attach)
return;
- dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+ dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir);
}
static void vb2_dc_finish(void *buf_priv)
@@ -129,7 +130,7 @@ static void vb2_dc_finish(void *buf_priv)
if (!sgt || buf->db_attach)
return;
- dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+ dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
}
/*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 39/86] ALSA: hda - Disable 64bit address for Creative HDA controllers
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Takashi Iwai
commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
We've had many reports that some Creative sound cards with CA0132
don't work well. Some reported that it starts working after reloading
the module, while some reported it starts working when a 32bit kernel
is used. All these facts seem implying that the chip fails to
communicate when the buffer is located in 64bit address.
This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
flag to the corresponding PCI entries. I casually had a chance to
test an SB Recon3D board, and indeed this seems helping.
Although this hasn't been tested on all Creative devices, it's safer
to assume that this restriction applies to the rest of them, too. So
the flag is applied to all Creative entries.
Signed-off-by: Takashi Iwai
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa
---
sound/pci/hda/hda_intel.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e0f076c..a52278f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -638,7 +638,8 @@ enum {
AZX_DCAPS_ALIGN_BUFSIZE | AZX_DCAPS_NO_64BIT)
#define AZX_DCAPS_PRESET_CTHDA \
- (AZX_DCAPS_NO_MSI | AZX_DCAPS_POSFIX_LPIB | AZX_DCAPS_4K_BDLE_BOUNDARY)
+ (AZX_DCAPS_NO_MSI | AZX_DCAPS_POSFIX_LPIB | AZX_DCAPS_4K_BDLE_BOUNDARY
|\
+AZX_DCAPS_NO_64BIT)
/*
* VGA-switcher support
@@ -4234,11 +4235,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
.class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
.class_mask = 0xff,
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
#else
/* this entry seems still valid -- i.e. without emu20kx chip */
{ PCI_DEVICE(0x1102, 0x0009),
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
#endif
/* Vortex86MX */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 18/86] mtd: mtdpart: fix add_mtd_partitions error path
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Boris BREZILLON
commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.
If we fail to allocate a partition structure in the middle of the partition
creation process, the already allocated partitions are never removed, which
means they are still present in the partition list and their resources are
never freed.
Signed-off-by: Boris Brezillon
Signed-off-by: Brian Norris
Signed-off-by: Kamal Mostafa
---
drivers/mtd/mtdpart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 6e732c3..51abd85 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -635,8 +635,10 @@ int add_mtd_partitions(struct mtd_info *master,
for (i = 0; i < nbparts; i++) {
slave = allocate_partition(master, parts + i, i, cur_offset);
- if (IS_ERR(slave))
+ if (IS_ERR(slave)) {
+ del_mtd_partitions(master);
return PTR_ERR(slave);
+ }
mutex_lock(_partitions_mutex);
list_add(>list, _partitions);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 41/86] megaraid_sas: Do not use PAGE_SIZE for max_sectors
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: "sumit.sax...@avagotech.com"
commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.
Do not use PAGE_SIZE marco to calculate max_sectors per I/O
request. Driver code assumes PAGE_SIZE will be always 4096 which can
lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
was reported in Ubuntu Bugzilla Bug #1475166.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
Reviewed-by: Martin K. Petersen
Signed-off-by: Martin K. Petersen
Signed-off-by: Kamal Mostafa
---
drivers/scsi/megaraid/megaraid_sas.h | 2 ++
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index e9e543c..d0caf0c 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -334,6 +334,8 @@ enum MR_EVT_ARGS {
MR_EVT_ARGS_GENERIC,
};
+
+#define SGE_BUFFER_SIZE4096
/*
* define constants for device list query options
*/
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9742005..c900e14 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3820,7 +3820,7 @@ static int megasas_init_fw(struct megasas_instance
*instance)
}
}
instance->max_sectors_per_req = instance->max_num_sge *
- PAGE_SIZE / 512;
+ SGE_BUFFER_SIZE / 512;
if (tmp_sectors && (instance->max_sectors_per_req > tmp_sectors))
instance->max_sectors_per_req = tmp_sectors;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 42/86] arm64: Fix compat register mappings
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Robin Murphy commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream. For reasons not entirely apparent, but now enshrined in history, the architectural mapping of AArch32 banked registers to AArch64 registers actually orders SP_ and LR_ backwards compared to the intuitive r13/r14 order, for all modes except FIQ. Fix the compat__ macros accordingly, in the hope of avoiding subtle bugs with KVM and AArch32 guests. Signed-off-by: Robin Murphy Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Kamal Mostafa --- arch/arm64/include/asm/ptrace.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h index 0e7fa49..428ae6f 100644 --- a/arch/arm64/include/asm/ptrace.h +++ b/arch/arm64/include/asm/ptrace.h @@ -71,14 +71,14 @@ #define compat_sp regs[13] #define compat_lr regs[14] #define compat_sp_hyp regs[15] -#define compat_sp_irq regs[16] -#define compat_lr_irq regs[17] -#define compat_sp_svc regs[18] -#define compat_lr_svc regs[19] -#define compat_sp_abt regs[20] -#define compat_lr_abt regs[21] -#define compat_sp_und regs[22] -#define compat_lr_und regs[23] +#define compat_lr_irq regs[16] +#define compat_sp_irq regs[17] +#define compat_lr_svc regs[18] +#define compat_sp_svc regs[19] +#define compat_lr_abt regs[20] +#define compat_sp_abt regs[21] +#define compat_lr_und regs[22] +#define compat_sp_und regs[23] #define compat_r8_fiq regs[24] #define compat_r9_fiq regs[25] #define compat_r10_fiq regs[26] -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 36/86] staging: rtl8712: Add device ID for Sitecom WLA2100
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Larry Finger
commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream.
This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
was checked to verify that the addition is correct.
Reported-by: Frans van de Wiel
Signed-off-by: Larry Finger
Cc: Frans van de Wiel
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
drivers/staging/rtl8712/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index bbd5888..11c7fcc 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -144,6 +144,7 @@ static struct usb_device_id rtl871x_usb_id_tbl[] = {
{USB_DEVICE(0x0DF6, 0x0058)},
{USB_DEVICE(0x0DF6, 0x0049)},
{USB_DEVICE(0x0DF6, 0x004C)},
+ {USB_DEVICE(0x0DF6, 0x006C)},
{USB_DEVICE(0x0DF6, 0x0064)},
/* Skyworth */
{USB_DEVICE(0x14b2, 0x3300)},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 43/86] can: Use correct type in sizeof() in nla_put()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Marek Vasut commit 562b103a21974c2f9cd67514d110f918bb3e1796 upstream. The sizeof() is invoked on an incorrect variable, likely due to some copy-paste error, and this might result in memory corruption. Fix this. Signed-off-by: Marek Vasut Cc: Wolfgang Grandegger Cc: net...@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Kamal Mostafa --- drivers/net/can/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index 3230ac8..5932b17 100644 --- a/drivers/net/can/dev.c +++ b/drivers/net/can/dev.c @@ -730,7 +730,7 @@ static int can_fill_info(struct sk_buff *skb, const struct net_device *dev) (priv->bittiming_const && nla_put(skb, IFLA_CAN_BITTIMING_CONST, sizeof(*priv->bittiming_const), priv->bittiming_const)) || - nla_put(skb, IFLA_CAN_CLOCK, sizeof(cm), >clock) || + nla_put(skb, IFLA_CAN_CLOCK, sizeof(priv->clock), >clock) || nla_put_u32(skb, IFLA_CAN_STATE, state) || nla_put(skb, IFLA_CAN_CTRLMODE, sizeof(cm), ) || nla_put_u32(skb, IFLA_CAN_RESTART_MS, priv->restart_ms) || -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 44/86] mtd: blkdevs: fix potential deadlock + lockdep warnings
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Brian Norris
commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream.
Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.
The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.
-> blktrans_open()
-> mutex_lock(>lock);
-> mutex_lock(_table_mutex);
-> del_mtd_device()
-> mutex_lock(_table_mutex);
-> blktrans_notify_remove() -> del_mtd_blktrans_dev()
-> mutex_lock(>lock);
This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired >lock:
if (mutex_trylock(_table_mutex)) {
mutex_unlock(_table_mutex);
BUG();
}
So, reverse the ordering of acquisition of >lock and _table_mutex so
we always acquire mtd_table_mutex first.
Snippets of the lockdep output follow:
# modprobe -r m25p80
[ 53.419251]
[ 53.420838] ==
[ 53.427300] [ INFO: possible circular locking dependency detected ]
[ 53.433865] 4.3.0-rc6 #96 Not tainted
[ 53.437686] ---
[ 53.444220] modprobe/372 is trying to acquire lock:
[ 53.449320] (>lock){+.+...}, at: []
del_mtd_blktrans_dev+0x80/0xdc
[ 53.457271]
[ 53.457271] but task is already holding lock:
[ 53.463372] (mtd_table_mutex){+.+.+.}, at: []
del_mtd_device+0x18/0x100
[ 53.471321]
[ 53.471321] which lock already depends on the new lock.
[ 53.471321]
[ 53.479856]
[ 53.479856] the existing dependency chain (in reverse order) is:
[ 53.487660]
-> #1 (mtd_table_mutex){+.+.+.}:
[ 53.492331][] blktrans_open+0x34/0x1a4
[ 53.497879][] __blkdev_get+0xc4/0x3b0
[ 53.503364][] blkdev_get+0x108/0x320
[ 53.508743][] do_dentry_open+0x218/0x314
[ 53.514496][] path_openat+0x4c0/0xf9c
[ 53.519959][] do_filp_open+0x5c/0xc0
[ 53.525336][] do_sys_open+0xfc/0x1cc
[ 53.530716][] ret_fast_syscall+0x0/0x1c
[ 53.536375]
-> #0 (>lock){+.+...}:
[ 53.540587][] mutex_lock_nested+0x38/0x3cc
[ 53.546504][] del_mtd_blktrans_dev+0x80/0xdc
[ 53.552606][] blktrans_notify_remove+0x7c/0x84
[ 53.558891][] del_mtd_device+0x74/0x100
[ 53.564544][] del_mtd_partitions+0x80/0xc8
[ 53.570451][] mtd_device_unregister+0x24/0x48
[ 53.576637][] spi_drv_remove+0x1c/0x34
[ 53.582207][] __device_release_driver+0x88/0x114
[ 53.588663][] device_release_driver+0x20/0x2c
[ 53.594843][] bus_remove_device+0xd8/0x108
[ 53.600748][] device_del+0x10c/0x210
[ 53.606127][] device_unregister+0xc/0x20
[ 53.611849][] __unregister+0x10/0x20
[ 53.617211][] device_for_each_child+0x50/0x7c
[ 53.623387][] spi_unregister_master+0x58/0x8c
[ 53.629578][] release_nodes+0x15c/0x1c8
[ 53.635223][] __device_release_driver+0x90/0x114
[ 53.641689][] driver_detach+0xb4/0xb8
[ 53.647147][] bus_remove_driver+0x4c/0xa0
[ 53.652970][] SyS_delete_module+0x11c/0x1e4
[ 53.658976][] ret_fast_syscall+0x0/0x1c
[ 53.664621]
[ 53.664621] other info that might help us debug this:
[ 53.664621]
[ 53.672979] Possible unsafe locking scenario:
[ 53.672979]
[ 53.679169]CPU0CPU1
[ 53.683900]
[ 53.688633] lock(mtd_table_mutex);
[ 53.692383]lock(>lock);
[ 53.698306]lock(mtd_table_mutex);
[ 53.704658] lock(>lock);
[ 53.707946]
[ 53.707946] *** DEADLOCK ***
Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount")
Reported-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Brian Norris
Signed-off-by: Kamal Mostafa
---
drivers/mtd/mtd_blkdevs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 32d5e40..48b63e8 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -198,8 +198,8 @@ static int blktrans_open(struct
[PATCH 3.13.y-ckt 17/86] net: mvneta: Fix CPU_MAP registers initialisation
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Maxime Ripard
commit 2502d0ef272da7058ef303b849a2c8dc324c2e2e upstream.
The CPU_MAP register is duplicated for each CPUs at different addresses,
each instance being at a different address.
However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP
registers for each registers, while the SoCs embed at most 4 CPUs.
This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS
is currently set to 16, resulting in writes to registers that are not
CPU_MAP.
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network
unit")
Signed-off-by: Maxime Ripard
Signed-off-by: Gregory CLEMENT
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index e23fbcc..05d247f 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -946,7 +946,7 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
/* Set CPU queue access map - all CPUs have access to all RX
* queues and to all TX queues
*/
- for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++)
+ for_each_present_cpu(cpu)
mvreg_write(pp, MVNETA_CPU_MAP(cpu),
(MVNETA_CPU_RXQ_ACCESS_ALL_MASK |
MVNETA_CPU_TXQ_ACCESS_ALL_MASK));
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc64: Add ADI capability to cpu capabilities
Add ADI (Application Data Integrity) capability to cpu capabilities list.
ADI capability allows virtual addresses to be encoded with a tag in
bits 63-60. This tag serves as an access control key for the regions
of virtual address with ADI enabled and a key set on them. Hypervisor
encodes this capability as "adp" in "hwcap-list" property in machine
description.
Signed-off-by: Khalid Aziz
---
arch/sparc/include/asm/elf_64.h | 1 +
arch/sparc/kernel/setup_64.c| 23 +++
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h
index 370ca1e..9331083 100644
--- a/arch/sparc/include/asm/elf_64.h
+++ b/arch/sparc/include/asm/elf_64.h
@@ -95,6 +95,7 @@
* really available. So we simply advertise only "crypto" support.
*/
#define HWCAP_SPARC_CRYPTO 0x0400 /* CRYPTO insns available */
+#define HWCAP_SPARC_ADI0x0800 /* ADI available */
#define CORE_DUMP_USE_REGSET
diff --git a/arch/sparc/kernel/setup_64.c b/arch/sparc/kernel/setup_64.c
index f7b2617..22c3566 100644
--- a/arch/sparc/kernel/setup_64.c
+++ b/arch/sparc/kernel/setup_64.c
@@ -380,7 +380,8 @@ static const char *hwcaps[] = {
*/
"mul32", "div32", "fsmuld", "v8plus", "popc", "vis", "vis2",
"ASIBlkInit", "fmaf", "vis3", "hpc", "random", "trans", "fjfmau",
- "ima", "cspare", "pause", "cbcond",
+ "ima", "cspare", "pause", "cbcond", NULL /*reserved for crypto */,
+ "adp",
};
static const char *crypto_hwcaps[] = {
@@ -396,9 +397,13 @@ void cpucap_info(struct seq_file *m)
seq_puts(m, "cpucaps\t\t: ");
for (i = 0; i < ARRAY_SIZE(hwcaps); i++) {
unsigned long bit = 1UL << i;
- if (caps & bit) {
- seq_printf(m, "%s%s",
- printed ? "," : "", hwcaps[i]);
+ if (hwcaps[i] && (caps & bit)) {
+ if (strcmp(hwcaps[i], "adp") == 0)
+ seq_printf(m, "%sadi",
+ printed ? "," : "");
+ else
+ seq_printf(m, "%s%s",
+ printed ? "," : "", hwcaps[i]);
printed++;
}
}
@@ -422,8 +427,10 @@ static void __init report_one_hwcap(int *printed, const
char *name)
{
if ((*printed) == 0)
printk(KERN_INFO "CPU CAPS: [");
- printk(KERN_CONT "%s%s",
- (*printed) ? "," : "", name);
+ if (strcmp(name, "adp") == 0)
+ pr_cont("%sadi", (*printed) ? "," : "");
+ else
+ pr_cont("%s%s", (*printed) ? "," : "", name);
if (++(*printed) == 8) {
printk(KERN_CONT "]\n");
*printed = 0;
@@ -450,7 +457,7 @@ static void __init report_hwcaps(unsigned long caps)
for (i = 0; i < ARRAY_SIZE(hwcaps); i++) {
unsigned long bit = 1UL << i;
- if (caps & bit)
+ if (hwcaps[i] && (caps & bit))
report_one_hwcap(, hwcaps[i]);
}
if (caps & HWCAP_SPARC_CRYPTO)
@@ -485,7 +492,7 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
for (i = 0; i < ARRAY_SIZE(hwcaps); i++) {
unsigned long bit = 1UL << i;
- if (!strcmp(prop, hwcaps[i])) {
+ if (hwcaps[i] && !strcmp(prop, hwcaps[i])) {
caps |= bit;
break;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/7] mm/gup: add gup trace points
For slow version, just add trace point for raw __get_user_pages since all
slow variants call it to do the real work finally.
Signed-off-by: Yang Shi
---
mm/gup.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index deafa2c..10245a4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -13,6 +13,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
#include
#include
@@ -462,6 +465,8 @@ long __get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
if (!nr_pages)
return 0;
+ trace_gup_get_user_pages(tsk, mm, start, nr_pages);
+
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
/*
@@ -599,6 +604,7 @@ int fixup_user_fault(struct task_struct *tsk, struct
mm_struct *mm,
if (!(vm_flags & vma->vm_flags))
return -EFAULT;
+ trace_gup_fixup_user_fault(tsk, mm, address, fault_flags);
ret = handle_mm_fault(mm, vma, address, fault_flags);
if (ret & VM_FAULT_ERROR) {
if (ret & VM_FAULT_OOM)
@@ -1340,6 +1346,8 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
start, len)))
return 0;
+ trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
+
/*
* Disable interrupts. We use the nested form as we can already have
* interrupts disabled by get_futex_key.
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/7] x86: mm/gup: add gup trace points
Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-off-by: Yang Shi --- arch/x86/mm/gup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c index ae9a37b..ed6cca9 100644 --- a/arch/x86/mm/gup.c +++ b/arch/x86/mm/gup.c @@ -10,6 +10,9 @@ #include #include +#define CREATE_TRACE_POINTS +#include > + #include static inline pte_t gup_get_pte(pte_t *ptep) @@ -270,6 +273,8 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write, (void __user *)start, len))) return 0; + trace_gup_get_user_pages_fast(start, nr_pages, write, pages); + /* * XXX: batch / limit 'nr', to avoid large irq off latency * needs some instrumenting to determine the common sizes used by @@ -342,6 +347,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write, goto slow_irqon; #endif + trace_gup_get_user_pages_fast(start, nr_pages, write, pages); + /* * XXX: batch / limit 'nr', to avoid large irq off latency * needs some instrumenting to determine the common sizes used by -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/7] mips: mm/gup: add gup trace points
Cc: linux-m...@linux-mips.org Acked-by: Ralf Baechle Signed-off-by: Yang Shi --- arch/mips/mm/gup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c index 349995d..3c5b8c8 100644 --- a/arch/mips/mm/gup.c +++ b/arch/mips/mm/gup.c @@ -12,6 +12,9 @@ #include #include +#define CREATE_TRACE_POINTS +#include + #include #include @@ -211,6 +214,8 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write, (void __user *)start, len))) return 0; + trace_gup_get_user_pages_fast(start, nr_pages, write, pages); + /* * XXX: batch / limit 'nr', to avoid large irq off latency * needs some instrumenting to determine the common sizes used by @@ -277,6 +282,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write, if (end < start || cpu_has_dc_aliases) goto slow_irqon; + trace_gup_get_user_pages_fast(start, nr_pages, write, pages); + /* XXX: batch / limit 'nr' */ local_irq_disable(); pgdp = pgd_offset(mm, addr); -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 6/7] sh: mm/gup: add gup trace points
Cc: linux...@vger.kernel.org
Signed-off-by: Yang Shi
---
arch/sh/mm/gup.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/sh/mm/gup.c b/arch/sh/mm/gup.c
index e7af6a6..6df3e97 100644
--- a/arch/sh/mm/gup.c
+++ b/arch/sh/mm/gup.c
@@ -12,6 +12,10 @@
#include
#include
#include
+
+#define CREATE_TRACE_POINTS
+#include
+
#include
static inline pte_t gup_get_pte(pte_t *ptep)
@@ -178,6 +182,8 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
(void __user *)start, len)))
return 0;
+ trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
+
/*
* This doesn't prevent pagetable teardown, but does prevent
* the pagetables and pages from being freed.
@@ -231,6 +237,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
if (end < start)
goto slow_irqon;
+ trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
+
local_irq_disable();
pgdp = pgd_offset(mm, addr);
do {
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/7] s390: mm/gup: add gup trace points
Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: linux-s...@vger.kernel.org Signed-off-by: Yang Shi --- arch/s390/mm/gup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/s390/mm/gup.c b/arch/s390/mm/gup.c index 12bbf0e..ac25e28 100644 --- a/arch/s390/mm/gup.c +++ b/arch/s390/mm/gup.c @@ -10,6 +10,10 @@ #include #include #include + +#define CREATE_TRACE_POINTS +#include + #include /* @@ -188,6 +192,9 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write, end = start + len; if ((end <= start) || (end > TASK_SIZE)) return 0; + + trace_gup_get_user_pages_fast(start, nr_pages, write, pages); + /* * local_irq_save() doesn't prevent pagetable teardown, but does * prevent the pagetables from being freed on s390. -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 46/86] crypto: algif_hash - Only export and import on sockets with data
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Herbert Xu
commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.
The hash_accept call fails to work on sockets that have not received
any data. For some algorithm implementations it may cause crashes.
This patch fixes this by ensuring that we only export and import on
sockets that have received data.
Reported-by: Harsh Jain
Signed-off-by: Herbert Xu
Tested-by: Stephan Mueller
Signed-off-by: Kamal Mostafa
---
crypto/algif_hash.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 8502462..a68b56a 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -192,9 +192,14 @@ static int hash_accept(struct socket *sock, struct socket
*newsock, int flags)
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
+ bool more;
int err;
- err = crypto_ahash_export(req, state);
+ lock_sock(sk);
+ more = ctx->more;
+ err = more ? crypto_ahash_export(req, state) : 0;
+ release_sock(sk);
+
if (err)
return err;
@@ -205,7 +210,10 @@ static int hash_accept(struct socket *sock, struct socket
*newsock, int flags)
sk2 = newsock->sk;
ask2 = alg_sk(sk2);
ctx2 = ask2->private;
- ctx2->more = 1;
+ ctx2->more = more;
+
+ if (!more)
+ return err;
err = crypto_ahash_import(>req, state);
if (err) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC V2] Add gup trace points support
Changelog V1 --> V2: Adopted commetns from Steven * remove all reference to tsk->comm since it is unnecessary for non-sched trace points * reduce arguments for __get_user_pages trace point and update mm/gup.c accordingly * Added Ralf's acked-by for patch 4/7. There is not content change for the trace points in arch specific mm/gup.c. Some background about why I think this might be useful. When I was profiling some hugetlb related program, I got page-faults event doubled when hugetlb is enabled. When I looked into the code, I found page-faults come from two places, do_page_fault and gup. So, I tried to figure out which play a role (or both) in my use case. But I can't find existing finer tracing event for sub page-faults in current mainline kernel. So, I added the gup trace points support to have finer tracing events for page-faults. The below events are added: __get_user_pages __get_user_pages_fast fixup_user_fault Both __get_user_pages and fixup_user_fault call handle_mm_fault. Just added trace points to raw version __get_user_pages since all variants will call it finally to do real work. Although __get_user_pages_fast doesn't call handle_mm_fault, it might be useful to have it to distinguish between slow and fast version. Yang Shi (7): trace/events: Add gup trace events mm/gup: add gup trace points x86: mm/gup: add gup trace points mips: mm/gup: add gup trace points s390: mm/gup: add gup trace points sh: mm/gup: add gup trace points sparc64: mm/gup: add gup trace points arch/mips/mm/gup.c | 7 +++ arch/s390/mm/gup.c | 7 +++ arch/sh/mm/gup.c | 8 arch/sparc/mm/gup.c| 8 arch/x86/mm/gup.c | 7 +++ include/trace/events/gup.h | 71 +++ mm/gup.c | 8 7 files changed, 116 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/7] trace/events: Add gup trace events
page-faults events record the invoke to handle_mm_fault, but the invoke
may come from do_page_fault or gup. In some use cases, the finer event count
mey be needed, so add trace events support for:
__get_user_pages
__get_user_pages_fast
fixup_user_fault
Signed-off-by: Yang Shi
---
include/trace/events/gup.h | 71 ++
1 file changed, 71 insertions(+)
create mode 100644 include/trace/events/gup.h
diff --git a/include/trace/events/gup.h b/include/trace/events/gup.h
new file mode 100644
index 000..03a4674
--- /dev/null
+++ b/include/trace/events/gup.h
@@ -0,0 +1,71 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM gup
+
+#if !defined(_TRACE_GUP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_GUP_H
+
+#include
+#include
+
+TRACE_EVENT(gup_fixup_user_fault,
+
+ TP_PROTO(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long address, unsigned int fault_flags),
+
+ TP_ARGS(tsk, mm, address, fault_flags),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, address )
+ ),
+
+ TP_fast_assign(
+ __entry->address= address;
+ ),
+
+ TP_printk("address=%lx", __entry->address)
+);
+
+TRACE_EVENT(gup_get_user_pages,
+
+ TP_PROTO(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, unsigned long nr_pages),
+
+ TP_ARGS(tsk, mm, start, nr_pages),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, start )
+ __field(unsigned long, nr_pages)
+ ),
+
+ TP_fast_assign(
+ __entry->start = start;
+ __entry->nr_pages = nr_pages;
+ ),
+
+ TP_printk("start=%lx nr_pages=%lu", __entry->start, __entry->nr_pages)
+);
+
+TRACE_EVENT(gup_get_user_pages_fast,
+
+ TP_PROTO(unsigned long start, int nr_pages, int write,
+ struct page **pages),
+
+ TP_ARGS(start, nr_pages, write, pages),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, start )
+ __field(unsigned long, nr_pages)
+ ),
+
+ TP_fast_assign(
+ __entry->start = start;
+ __entry->nr_pages = nr_pages;
+ ),
+
+ TP_printk("start=%lx nr_pages=%lu", __entry->start, __entry->nr_pages)
+);
+
+#endif /* _TRACE_GUP_H */
+
+/* This part must be outside protection */
+#include
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 13/86] net: fix a race in dst_release()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Eric Dumazet
[ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ]
Only cpu seeing dst refcount going to 0 can safely
dereference dst->flags.
Otherwise an other cpu might already have freed the dst.
Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
Reported-by: Greg Thelen
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/core/dst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 15b6792..c070705 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -283,7 +283,7 @@ void dst_release(struct dst_entry *dst)
newrefcnt = atomic_dec_return(>__refcnt);
WARN_ON(newrefcnt < 0);
- if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt)
+ if (!newrefcnt && unlikely(dst->flags & DST_NOCACHE))
call_rcu(>rcu_head, dst_destroy_rcu);
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 48/86] megaraid_sas : SMAP restriction--do not access user memory from IOCTL code
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: "sumit.sax...@avagotech.com"
commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.
This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
Signed-off-by: Martin K. Petersen
Signed-off-by: Kamal Mostafa
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index c900e14..aca7b66 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5280,6 +5280,9 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
int i;
int error = 0;
compat_uptr_t ptr;
+ unsigned long local_raw_ptr;
+ u32 local_sense_off;
+ u32 local_sense_len;
if (clear_user(ioc, sizeof(*ioc)))
return -EFAULT;
@@ -5297,9 +5300,15 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
* sense_len is not null, so prepare the 64bit value under
* the same condition.
*/
- if (ioc->sense_len) {
+ if (get_user(local_raw_ptr, ioc->frame.raw) ||
+ get_user(local_sense_off, >sense_off) ||
+ get_user(local_sense_len, >sense_len))
+ return -EFAULT;
+
+
+ if (local_sense_len) {
void __user **sense_ioc_ptr =
- (void __user **)(ioc->frame.raw + ioc->sense_off);
+ (void __user **)((u8*)local_raw_ptr + local_sense_off);
compat_uptr_t *sense_cioc_ptr =
(compat_uptr_t *)(cioc->frame.raw + cioc->sense_off);
if (get_user(ptr, sense_cioc_ptr) ||
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 49/86] mac80211: allow null chandef in tracing
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Arik Nemtsov
commit 254d3dfe445f94a764e399ca12e04365ac9413ed upstream.
In TDLS channel-switch operations the chandef can sometimes be NULL.
Avoid an oops in the trace code for these cases and just print a
chandef full of zeros.
Fixes: a7a6bdd0670fe ("mac80211: introduce TDLS channel switch ops")
Signed-off-by: Arik Nemtsov
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
Signed-off-by: Kamal Mostafa
---
net/mac80211/trace.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index d4cee98..383884d 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -32,11 +32,11 @@
__field(u32, chan_width)
\
__field(u32, center_freq1)
\
__field(u32, center_freq2)
-#define CHANDEF_ASSIGN(c)
\
- __entry->control_freq = (c)->chan ?
(c)->chan->center_freq : 0; \
- __entry->chan_width = (c)->width;
\
- __entry->center_freq1 = (c)->center_freq1;
\
- __entry->center_freq2 = (c)->center_freq2;
+#define CHANDEF_ASSIGN(c)
\
+ __entry->control_freq = (c) ? ((c)->chan ?
(c)->chan->center_freq : 0) : 0; \
+ __entry->chan_width = (c) ? (c)->width : 0;
\
+ __entry->center_freq1 = (c) ? (c)->center_freq1 : 0;
\
+ __entry->center_freq2 = (c) ? (c)->center_freq2 : 0;
#define CHANDEF_PR_FMT " control:%d MHz width:%d center: %d/%d MHz"
#define CHANDEF_PR_ARG __entry->control_freq, __entry->chan_width,
\
__entry->center_freq1, __entry->center_freq2
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 45/86] Revert "dm mpath: fix stalls when handling invalid ioctls"
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mauricio Faria de Oliveira
commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream.
This reverts commit a1989b330093578ea5470bea0a00f940c444c466.
That commit introduced a regression at least for the case of the SG_IO ioctl()
running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there
are no active paths: the ioctl() fails with the ENOTTY errno immediately rather
than blocking due to queue_if_no_path until a path becomes active, for example.
That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
(qemu "-device scsi-block" [1], libvirt "" [2])
from multipath devices; which leads to SCSI/filesystem errors in such a guest.
More general scenarios can hit that regression too. The following demonstration
employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective
(some output & user changes omitted for brevity and comments added for clarity).
Reverting that commit restores normal operation (queueing) in failing scenarios;
tested on linux-next (next-20151022).
1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM)
$ cat sg_simple0.c
... see [3] ...
$ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c
$ gcc sgio_inquiry.c -o sgio_inquiry
2) The ioctl() works fine with active paths present.
# multipath -l 85ag56
85ag56 (...) dm-19 IBM ,2145
size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| |- 8:0:11:0 sdz 65:144 active undef running
| `- 9:0:9:0 sdbf 67:144 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
|- 8:0:12:0 sdae 65:224 active undef running
`- 9:0:12:0 sdbo 68:32 active undef running
$ ./sgio_inquiry /dev/mapper/85ag56
Some of the INQUIRY command's response:
IBM 2145
INQUIRY duration=0 millisecs, resid=0
3) The ioctl() fails with ENOTTY errno with _no_ active paths present,
for unprivileged users (rather than blocking due to queue_if_no_path).
# for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \
do multipathd -k"fail path $path"; done
# multipath -l 85ag56
85ag56 (...) dm-19 IBM ,2145
size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 8:0:11:0 sdz 65:144 failed undef running
| `- 9:0:9:0 sdbf 67:144 failed undef running
`-+- policy='service-time 0' prio=0 status=enabled
|- 8:0:12:0 sdae 65:224 failed undef running
`- 9:0:12:0 sdbo 68:32 failed undef running
$ ./sgio_inquiry /dev/mapper/85ag56
sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device
4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().
$ dmesg
<...>
[] device-mapper: multipath: Failing path 65:144.
[] device-mapper: multipath: Failing path 67:144.
[] device-mapper: multipath: Failing path 65:224.
[] device-mapper: multipath: Failing path 68:32.
[] sgio_inquiry: sending ioctl 2285 to a partition!
5) The ioctl() only works if the SYS_CAP_RAWIO capability is present
(then queueing happens -- in this example, queue_if_no_path is set);
this is due to a conditional check in scsi_verify_blk_ioctl().
# capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56'
sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device
# ./sgio_inquiry /dev/mapper/85ag56 &
[1] 72830
# cat /proc/72830/stack
[] 0xc0171c0df700
[] __switch_to+0x204/0x350
[] msleep+0x5c/0x80
[] dm_blk_ioctl+0x70/0x170
[] blkdev_ioctl+0x2b0/0x9b0
[] block_ioctl+0x64/0xd0
[] do_vfs_ioctl+0x490/0x780
[] SyS_ioctl+0xd4/0xf0
[] system_call+0x38/0xd0
6) This is the function call chain exercised in this analysis:
SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c
-> do_vfs_ioctl()
-> vfs_ioctl()
...
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
...
-> dm_blk_ioctl() @ drivers/md/dm.c
-> multipath_ioctl() @ drivers/md/dm-mpath.c
...
(bdev = NULL, due to no active paths)
...
if (!bdev || <...>) {
int err = scsi_verify_blk_ioctl(NULL, cmd);
if (err)
r = err;
}
...
-> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c
...
if (bd && bd == bd->bd_contains) // not taken
(bd = NULL)
[PATCH 3.13.y-ckt 51/86] KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Feng Wu
commit e1e746b3c55d1d1e0841a2e600a154d8f6747232 upstream.
SMAP is disabled if CPU is in non-paging mode in hardware.
However KVM always uses paging mode to emulate guest non-paging
mode with TDP. To emulate this behavior, SMAP needs to be
manually disabled when guest switches to non-paging mode.
Signed-off-by: Feng Wu
Signed-off-by: Marcelo Tosatti
[ kamal: 3.13-stable prereq for
656ec4a KVM: VMX: fix SMEP and SMAP without EPT ]
Signed-off-by: Kamal Mostafa
---
arch/x86/kvm/vmx.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9c2c662..45019f0 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3429,13 +3429,14 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned
long cr4)
hw_cr4 &= ~X86_CR4_PAE;
hw_cr4 |= X86_CR4_PSE;
/*
-* SMEP is disabled if CPU is in non-paging mode in
-* hardware. However KVM always uses paging mode to
+* SMEP/SMAP is disabled if CPU is in non-paging mode
+* in hardware. However KVM always uses paging mode to
* emulate guest non-paging mode with TDP.
-* To emulate this behavior, SMEP needs to be manually
-* disabled when guest switches to non-paging mode.
+* To emulate this behavior, SMEP/SMAP needs to be
+* manually disabled when guest switches to non-paging
+* mode.
*/
- hw_cr4 &= ~X86_CR4_SMEP;
+ hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
} else if (!(cr4 & X86_CR4_PAE)) {
hw_cr4 &= ~X86_CR4_PAE;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 50/86] recordmcount: Fix endianness handling bug for nop_mcount
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: libin
commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.
In nop_mcount, shdr->sh_offset and welp->r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.
Link: http://lkml.kernel.org/r/563806c7.7070...@huawei.com
Signed-off-by: Li Bin
Signed-off-by: Steven Rostedt
Signed-off-by: Kamal Mostafa
---
scripts/recordmcount.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 49b582a..b9897e2 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -377,7 +377,7 @@ static void nop_mcount(Elf_Shdr const *const relhdr,
if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
if (make_nop)
- ret = make_nop((void *)ehdr, shdr->sh_offset +
relp->r_offset);
+ ret = make_nop((void *)ehdr,
_w(shdr->sh_offset) + _w(relp->r_offset));
if (warn_on_notrace_sect && !once) {
printf("Section %s has mcount callers being
ignored\n",
txtname);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 14/86] [3.13-stable only] fib_rules: Fix dump_rules() not to exit early
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Roland Dreier
Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
multiple skbs") introduced a regression in "ip rule show" - it ends up
dumping the first rule over and over and never exiting, because 3.19
and earlier are missing commit 053c095a82cf ("netlink: make
nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
returning skb->len (i.e. > 0) in the success case.
Fix this by checking the return code for < 0 instead of != 0.
Signed-off-by: Roland Dreier
Signed-off-by: Kamal Mostafa
---
net/core/fib_rules.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index aeedc3a..99ae718 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -631,7 +631,7 @@ static int dump_rules(struct sk_buff *skb, struct
netlink_callback *cb,
err = fib_nl_fill_rule(skb, rule, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, RTM_NEWRULE,
NLM_F_MULTI, ops);
- if (err)
+ if (err < 0)
break;
skip:
idx++;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 53/86] ALSA: hda - Apply pin fixup for HP ProBook 6550b
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Takashi Iwai
commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.
HP ProBook 6550b needs the same pin fixup applied to other HP B-series
laptops with docks for making its headphone and dock headphone jacks
working properly. We just need to add the codec SSID to the list.
Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal Mostafa
---
sound/pci/hda/patch_sigmatel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 33282e5..3629164 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -708,6 +708,7 @@ static bool hp_bnb2011_with_dock(struct hda_codec *codec)
static bool hp_blike_system(u32 subsystem_id)
{
switch (subsystem_id) {
+ case 0x103c1473: /* HP ProBook 6550b */
case 0x103c1520:
case 0x103c1521:
case 0x103c1523:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 52/86] KVM: VMX: fix SMEP and SMAP without EPT
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?=
commit 656ec4a4928a3db7d16e5cb9bce351a478cfd3d5 upstream.
The comment in code had it mostly right, but we enable paging for
emulated real mode regardless of EPT.
Without EPT (which implies emulated real mode), secondary VCPUs won't
start unless we disable SM[AE]P when the guest doesn't use paging.
Signed-off-by: Radim Krčmář
Signed-off-by: Paolo Bonzini
Signed-off-by: Kamal Mostafa
---
arch/x86/kvm/vmx.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 45019f0..4b7094e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3428,20 +3428,21 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned
long cr4)
if (!is_paging(vcpu)) {
hw_cr4 &= ~X86_CR4_PAE;
hw_cr4 |= X86_CR4_PSE;
- /*
-* SMEP/SMAP is disabled if CPU is in non-paging mode
-* in hardware. However KVM always uses paging mode to
-* emulate guest non-paging mode with TDP.
-* To emulate this behavior, SMEP/SMAP needs to be
-* manually disabled when guest switches to non-paging
-* mode.
-*/
- hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
} else if (!(cr4 & X86_CR4_PAE)) {
hw_cr4 &= ~X86_CR4_PAE;
}
}
+ if (!enable_unrestricted_guest && !is_paging(vcpu))
+ /*
+* SMEP/SMAP is disabled if CPU is in non-paging mode in
+* hardware. However KVM always uses paging mode without
+* unrestricted guest.
+* To emulate this behavior, SMEP/SMAP needs to be manually
+* disabled when guest switches to non-paging mode.
+*/
+ hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
+
vmcs_writel(CR4_READ_SHADOW, cr4);
vmcs_writel(GUEST_CR4, hw_cr4);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 12/86] net: avoid NULL deref in inet_ctl_sock_destroy()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Eric Dumazet
[ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ]
Under low memory conditions, tcp_sk_init() and icmp_sk_init()
can both iterate on all possible cpus and call inet_ctl_sock_destroy(),
with eventual NULL pointer.
Signed-off-by: Eric Dumazet
Reported-by: Dmitry Vyukov
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
include/net/inet_common.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/inet_common.h b/include/net/inet_common.h
index fe7994c..fd1da04 100644
--- a/include/net/inet_common.h
+++ b/include/net/inet_common.h
@@ -40,7 +40,8 @@ int inet_ctl_sock_create(struct sock **sk, unsigned short
family,
static inline void inet_ctl_sock_destroy(struct sock *sk)
{
- sk_release_kernel(sk);
+ if (sk)
+ sk_release_kernel(sk);
}
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] mm, oom: avoid attempting to kill init sharing same memory
From: Chen Jie It's possible that an oom killed victim shares an ->mm with the init process and thus oom_kill_process() would end up trying to kill init as well. This has been shown in practice: Out of memory: Kill process 9134 (init) score 3 or sacrifice child Killed process 9134 (init) total-vm:1868kB, anon-rss:84kB, file-rss:572kB Kill process 1 (init) sharing same memory ... Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 And this will result in a kernel panic. If a process is forked by init and selected for oom kill while still sharing init_mm, then it's likely this system is in a recoverable state. However, it's better not to try to kill init and allow the machine to panic due to unkillable processes. [rient...@google.com: rewrote changelog] Acked-by: Michal Hocko Signed-off-by: Chen Jie Signed-off-by: David Rientjes --- I removed stable from this patch since the alternative would most likely be to panic the system for no killable processes anyway. There's a very small likelihood this patch would allow for a recoverable system. mm/oom_kill.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/oom_kill.c b/mm/oom_kill.c --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -608,6 +608,8 @@ void oom_kill_process(struct oom_control *oc, struct task_struct *p, continue; if (unlikely(p->flags & PF_KTHREAD)) continue; + if (!is_global_init(p)) + continue; if (p->signal->oom_score_adj == OOM_SCORE_ADJ_MIN) continue; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 57/86] printk: prevent userland from spoofing kernel messages
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mathias Krause
commit 3824657c522f19f85a76bd932821174a5557a382 upstream.
The following statement of ABI/testing/dev-kmsg is not quite right:
It is not possible to inject messages from userspace with the
facility number LOG_KERN (0), to make sure that the origin of the
messages can always be reliably determined.
Userland actually can inject messages with a facility of 0 by abusing the
fact that the facility is stored in a u8 data type. By using a facility
which is a multiple of 256 the assignment of msg->facility in log_store()
implicitly truncates it to 0, i.e. LOG_KERN, allowing users of /dev/kmsg
to spoof kernel messages as shown below:
The following call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
user :emerg : [ 66.137758] Kernel panic - not syncing: beer empty
However, this call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
kern :emerg : [ 74.177343] Kernel panic - not syncing: beer empty
Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.
Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause
Cc: Greg Kroah-Hartman
Cc: Petr Mladek
Cc: Alex Elder
Cc: Joe Perches
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[ kamal: backport to 3.13-stable: retain local 'int i' ]
Signed-off-by: Kamal Mostafa
---
kernel/printk/printk.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9b6f5d2..322df13 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -239,6 +239,9 @@ static u32 clear_idx;
#define PREFIX_MAX 32
#define LOG_LINE_MAX 1024 - PREFIX_MAX
+#define LOG_LEVEL(v) ((v) & 0x07)
+#define LOG_FACILITY(v)((v) >> 3 & 0xff)
+
/* record buffer */
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
#define LOG_ALIGN 4
@@ -452,12 +455,13 @@ static ssize_t devkmsg_writev(struct kiocb *iocb, const
struct iovec *iv,
line = buf;
if (line[0] == '<') {
char *endp = NULL;
+ unsigned int u;
- i = simple_strtoul(line+1, , 10);
+ u = simple_strtoul(line + 1, , 10);
if (endp && endp[0] == '>') {
- level = i & 7;
- if (i >> 3)
- facility = i >> 3;
+ level = LOG_LEVEL(u);
+ if (LOG_FACILITY(u) != 0)
+ facility = LOG_FACILITY(u);
endp++;
len -= endp - line;
line = endp;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 55/86] firewire: ohci: fix JMicron JMB38x IT context discovery
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Stefan Richter
commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.
Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
controllers: Often or even most of the time, the controller is
initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts
(IT contexts), applications like audio output are impossible.
However, OHCI-1394 demands that at least 4 IT contexts are implemented
by the link layer controller, and indeed JMicron JMB38x do implement
four of them. Only their IsoXmitIntMask register is unreliable at early
access.
With my own JMB381 single function controller I found:
- I can reproduce the problem with a lower probability than Craig's.
- If I put a loop around the section which clears and reads
IsoXmitIntMask, then either the first or the second attempt will
return the correct initial mask of 0x000f. I never encountered
a case of needing more than a second attempt.
- Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
before the first write, the subsequent read will return the correct
result.
- If I merely ignore a wrong read result and force the known real
result, later isochronous transmit DMA usage works just fine.
So let's just fix this chip bug up by the latter method. Tested with
JMB381 on kernel 3.13 and 4.3.
Since OHCI-1394 generally requires 4 IT contexts at a minium, this
workaround is simply applied whenever the initial read of IsoXmitIntMask
returns 0, regardless whether it's a JMicron chip or not. I never heard
of this issue together with any other chip though.
I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
and JMB388 combo controllers exactly the same as on the JMB381 single-
function controller, but so far I haven't had a chance to let an owner
of a combo chip run a patched kernel.
Strangely enough, IsoRecvIntMask is always reported correctly, even
though it is probed right before IsoXmitIntMask.
Reported-by: Clifford Dunn
Reported-by: Craig Moore
Signed-off-by: Stefan Richter
Signed-off-by: Kamal Mostafa
---
drivers/firewire/ohci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index ee805a5..81b45c4 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -3672,6 +3672,11 @@ static int pci_probe(struct pci_dev *dev,
reg_write(ohci, OHCI1394_IsoXmitIntMaskSet, ~0);
ohci->it_context_support = reg_read(ohci, OHCI1394_IsoXmitIntMaskSet);
+ /* JMicron JMB38x often shows 0 at first read, just ignore it */
+ if (!ohci->it_context_support) {
+ ohci_notice(ohci, "overriding IsoXmitIntMask\n");
+ ohci->it_context_support = 0xf;
+ }
reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, ~0);
ohci->it_context_mask = ohci->it_context_support;
ohci->n_it = hweight32(ohci->it_context_mask);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 47/86] xtensa: fixes for configs without loop option
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Max Filippov commit 5029615e25dc5040beb065f36743c127a8e51497 upstream. Build-time fixes: - make lbeg/lend/lcount save/restore conditional on kernel entry; - don't clear lcount in platform_restart functions unconditionally. Run-time fixes: - use correct end of range register in __endla paired with __loopt, not the unused temporary register. This fixes .bss zero-initialization. Update comments in asmmacro.h; - don't clobber a10 in the usercopy that leads to access to unmapped memory. Signed-off-by: Max Filippov [ luis: backported to 3.16: adjusted context ] Signed-off-by: Luis Henriques Signed-off-by: Kamal Mostafa --- arch/xtensa/include/asm/asmmacro.h | 7 --- arch/xtensa/kernel/entry.S | 8 ++-- arch/xtensa/kernel/head.S| 2 +- arch/xtensa/lib/usercopy.S | 6 +++--- arch/xtensa/platforms/iss/setup.c| 2 ++ arch/xtensa/platforms/xt2000/setup.c | 2 ++ arch/xtensa/platforms/xtfpga/setup.c | 2 ++ 7 files changed, 20 insertions(+), 9 deletions(-) diff --git a/arch/xtensa/include/asm/asmmacro.h b/arch/xtensa/include/asm/asmmacro.h index 755320f..746dcc8 100644 --- a/arch/xtensa/include/asm/asmmacro.h +++ b/arch/xtensa/include/asm/asmmacro.h @@ -35,9 +35,10 @@ * __loop as *restart loop. 'as' register must not have been modified! * - * __endla ar, at, incr + * __endla ar, as, incr *ar start address (modified) - *as scratch register used by macro + *as scratch register used by __loops/__loopi macros or + * end address used by __loopt macro *inc increment */ @@ -97,7 +98,7 @@ .endm /* - * loop from ar to ax + * loop from ar to as */ .macro __loopt ar, as, at, incr_log2 diff --git a/arch/xtensa/kernel/entry.S b/arch/xtensa/kernel/entry.S index 250c52b..907bc27 100644 --- a/arch/xtensa/kernel/entry.S +++ b/arch/xtensa/kernel/entry.S @@ -335,8 +335,10 @@ common_exception: s32ia2, a1, PT_SYSCALL movia2, 0 s32ia3, a1, PT_EXCVADDR +#if XCHAL_HAVE_LOOPS xsr a2, lcount s32ia2, a1, PT_LCOUNT +#endif /* It is now save to restore the EXC_TABLE_FIXUP variable. */ @@ -368,11 +370,12 @@ common_exception: s32ia3, a1, PT_PS # save ps /* Save lbeg, lend */ - +#if XCHAL_HAVE_LOOPS rsr a2, lbeg rsr a3, lend s32ia2, a1, PT_LBEG s32ia3, a1, PT_LEND +#endif /* Save SCOMPARE1 */ @@ -664,13 +667,14 @@ common_exception_exit: wsr a3, sar /* Restore LBEG, LEND, LCOUNT */ - +#if XCHAL_HAVE_LOOPS l32ia2, a1, PT_LBEG l32ia3, a1, PT_LEND wsr a2, lbeg l32ia2, a1, PT_LCOUNT wsr a3, lend wsr a2, lcount +#endif /* We control single stepping through the ICOUNTLEVEL register. */ diff --git a/arch/xtensa/kernel/head.S b/arch/xtensa/kernel/head.S index 7d740eb..1ae90af 100644 --- a/arch/xtensa/kernel/head.S +++ b/arch/xtensa/kernel/head.S @@ -219,7 +219,7 @@ ENTRY(_startup) __loopt a2, a3, a4, 2 s32ia0, a2, 0 - __endla a2, a4, 4 + __endla a2, a3, 4 #if XCHAL_DCACHE_IS_WRITEBACK diff --git a/arch/xtensa/lib/usercopy.S b/arch/xtensa/lib/usercopy.S index ace1892..7ea4dd6 100644 --- a/arch/xtensa/lib/usercopy.S +++ b/arch/xtensa/lib/usercopy.S @@ -222,8 +222,8 @@ __xtensa_copy_user: loopnez a7, .Loop2done #else /* !XCHAL_HAVE_LOOPS */ beqza7, .Loop2done - sllia10, a7, 4 - add a10, a10, a3# a10 = end of last 16B source chunk + sllia12, a7, 4 + add a12, a12, a3# a12 = end of last 16B source chunk #endif /* !XCHAL_HAVE_LOOPS */ .Loop2: EX(l32i, a7, a3, 4, l_fixup) @@ -241,7 +241,7 @@ __xtensa_copy_user: EX(s32i, a9, a5, 12, s_fixup) addia5, a5, 16 #if !XCHAL_HAVE_LOOPS - blt a3, a10, .Loop2 + blt a3, a12, .Loop2 #endif /* !XCHAL_HAVE_LOOPS */ .Loop2done: bbci.l a4, 3, .L12 diff --git a/arch/xtensa/platforms/iss/setup.c b/arch/xtensa/platforms/iss/setup.c index da7d182..3918205 100644 --- a/arch/xtensa/platforms/iss/setup.c +++ b/arch/xtensa/platforms/iss/setup.c @@ -61,7 +61,9 @@ void platform_restart(void) #if XCHAL_NUM_IBREAK > 0 "wsr a2, ibreakenable\n\t" #endif +#if XCHAL_HAVE_LOOPS "wsr a2, lcount\n\t" +#endif "movi a2, 0x1f\n\t" "wsr a2, ps\n\t" "isync\n\t" diff --git a/arch/xtensa/platforms/xt2000/setup.c b/arch/xtensa/platforms/xt2000/setup.c index f9bc879..338a8cf 100644 --- a/arch/xtensa/platforms/xt2000/setup.c +++ b/arch/xtensa/platforms/xt2000/setup.c @@ -72,7 +72,9 @@
[PATCH 3.13.y-ckt 59/86] Btrfs: fix race leading to incorrect item deletion when dropping extents
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Filipe Manana
commit aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c upstream.
While running a stress test I got the following warning triggered:
[191627.672810] [ cut here ]
[191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779
__btrfs_drop_extents+0x391/0xa50 [btrfs]()
(...)
[191627.701485] Call Trace:
[191627.702037] [] dump_stack+0x4f/0x7b
[191627.702992] [] ? console_unlock+0x356/0x3a2
[191627.704091] [] warn_slowpath_common+0xa1/0xbb
[191627.705380] [] ? __btrfs_drop_extents+0x391/0xa50
[btrfs]
[191627.706637] [] warn_slowpath_null+0x1a/0x1c
[191627.707789] [] __btrfs_drop_extents+0x391/0xa50 [btrfs]
[191627.709155] [] ?
cache_alloc_debugcheck_after.isra.32+0x171/0x1d0
[191627.712444] [] ?
kmemleak_alloc_recursive.constprop.40+0x16/0x18
[191627.714162] []
insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs]
[191627.715887] [] ? start_transaction+0x3bb/0x610 [btrfs]
[191627.717287] [] btrfs_finish_ordered_io+0x273/0x4e2
[btrfs]
[191627.728865] [] finish_ordered_fn+0x15/0x17 [btrfs]
[191627.730045] [] normal_work_helper+0x14c/0x32c [btrfs]
[191627.731256] [] btrfs_endio_write_helper+0x12/0x14
[btrfs]
[191627.732661] [] process_one_work+0x24c/0x4ae
[191627.733822] [] worker_thread+0x206/0x2c2
[191627.734857] [] ? process_scheduled_works+0x2f/0x2f
[191627.736052] [] ? process_scheduled_works+0x2f/0x2f
[191627.737349] [] kthread+0xef/0xf7
[191627.738267] [] ? time_hardirqs_on+0x15/0x28
[191627.739330] [] ? __kthread_parkme+0xad/0xad
[191627.741976] [] ret_from_fork+0x42/0x70
[191627.743080] [] ? __kthread_parkme+0xad/0xad
[191627.744206] ---[ end trace bbfddacb7aaada8d ]---
$ cat -n fs/btrfs/file.c
691 int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
(...)
758 btrfs_item_key_to_cpu(leaf, , path->slots[0]);
759 if (key.objectid > ino ||
760 key.type > BTRFS_EXTENT_DATA_KEY || key.offset >=
end)
761 break;
762
763 fi = btrfs_item_ptr(leaf, path->slots[0],
764 struct btrfs_file_extent_item);
765 extent_type = btrfs_file_extent_type(leaf, fi);
766
767 if (extent_type == BTRFS_FILE_EXTENT_REG ||
768 extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
(...)
774 } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
(...)
778 } else {
779 WARN_ON(1);
780 extent_end = search_start;
781 }
(...)
This happened because the item we were processing did not match a file
extent item (its key type != BTRFS_EXTENT_DATA_KEY), and even on this
case we cast the item to a struct btrfs_file_extent_item pointer and
then find a type field value that does not match any of the expected
values (BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]). This scenario happens
due to a tiny time window where a race can happen as exemplified below.
For example, consider the following scenario where we're using the
NO_HOLES feature and we have the following two neighbour leafs:
Leaf X (has N items)Leaf Y
[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ]
slot N - 2 slot N - 1 slot 0
Our inode 257 has an implicit hole in the range [0, 8K[ (implicit rather
than explicit because NO_HOLES is enabled). Now if our inode has an
ordered extent for the range [4K, 8K[ that is finishing, the following
can happen:
CPU 1 CPU 2
btrfs_finish_ordered_io()
insert_reserved_file_extent()
__btrfs_drop_extents()
Searches for the key
(257 EXTENT_DATA 4096) through
btrfs_lookup_file_extent()
Key not found and we get a path where
path->nodes[0] == leaf X and
path->slots[0] == N
Because path->slots[0] is >=
btrfs_header_nritems(leaf X), we call
btrfs_next_leaf()
btrfs_next_leaf() releases the path
inserts key
(257 INODE_REF 4096)
at the end of leaf X,
leaf X now has N + 1 keys,
and the new key is at
slot N
btrfs_next_leaf() searches for
key (257 INODE_REF 256), with
path->keep_locks set to 1,
because it was the last key it
saw in leaf X
finds it in leaf X again and
notices it's no longer the last
Re: [PATCH v6 03/10] mtd: fsl-quadspi: return amount of data read/written or error
On Wed, Dec 02, 2015 at 03:06:28PM -0600, Han Xu wrote: > On Wed, Dec 02, 2015 at 10:38:19AM +, Michal Suchanek wrote: > > Return amount of data read/written or error as read(2)/write(2) does. > > > > Signed-off-by: Michal Suchanek > > --- > > drivers/mtd/spi-nor/fsl-quadspi.c | 18 +++--- > > 1 file changed, 11 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c > > b/drivers/mtd/spi-nor/fsl-quadspi.c > > index 10d2b59..9beb739 100644 > > --- a/drivers/mtd/spi-nor/fsl-quadspi.c > > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c > > @@ -575,7 +575,7 @@ static inline void fsl_qspi_invalid(struct fsl_qspi *q) > > writel(reg, q->iobase + QUADSPI_MCR); > > } > > > > -static int fsl_qspi_nor_write(struct fsl_qspi *q, struct spi_nor *nor, > > +static ssize_t fsl_qspi_nor_write(struct fsl_qspi *q, struct spi_nor *nor, > > conflict with the patch I acked. > > https://patchwork.ozlabs.org/patch/545925/ > > I may change it and test on my side. I'll let you know if I need things rebased. If conflicts are trivial, I can handle it. But right now, the linked patch (big endian support) is incomplete (no documentation), and Michal's was just sent today. So it remains to be seen which will be "ready" first. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 63/86] Btrfs: fix race when listing an inode's xattrs
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Filipe Manana
commit f1cd1f0b7d1b5d4aaa5711e8f4e4898b0045cb6d upstream.
When listing a inode's xattrs we have a time window where we race against
a concurrent operation for adding a new hard link for our inode that makes
us not return any xattr to user space. In order for this to happen, the
first xattr of our inode needs to be at slot 0 of a leaf and the previous
leaf must still have room for an inode ref (or extref) item, and this can
happen because an inode's listxattrs callback does not lock the inode's
i_mutex (nor does the VFS does it for us), but adding a hard link to an
inode makes the VFS lock the inode's i_mutex before calling the inode's
link callback.
If we have the following leafs:
Leaf X (has N items)Leaf Y
[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 XATTR_ITEM 12345), ... ]
slot N - 2 slot N - 1 slot 0
The race illustrated by the following sequence diagram is possible:
CPU 1 CPU 2
btrfs_listxattr()
searches for key (257 XATTR_ITEM 0)
gets path with path->nodes[0] == leaf X
and path->slots[0] == N
because path->slots[0] is >=
btrfs_header_nritems(leaf X), it calls
btrfs_next_leaf()
btrfs_next_leaf()
releases the path
adds key (257 INODE_REF 666)
to the end of leaf X (slot
N),
and leaf X now has N + 1
items
searches for the key (257 INODE_REF 256),
with path->keep_locks == 1, because that
is the last key it saw in leaf X before
releasing the path
ends up at leaf X again and it verifies
that the key (257 INODE_REF 256) is no
longer the last key in leaf X, so it
returns with path->nodes[0] == leaf X
and path->slots[0] == N, pointing to
the new item with key (257 INODE_REF 666)
btrfs_listxattr's loop iteration sees that
the type of the key pointed by the path is
different from the type BTRFS_XATTR_ITEM_KEY
and so it breaks the loop and stops looking
for more xattr items
--> the application doesn't get any xattr
listed for our inode
So fix this by breaking the loop only if the key's type is greater than
BTRFS_XATTR_ITEM_KEY and skip the current key if its type is smaller.
Signed-off-by: Filipe Manana
[ luis: backported to 3.16:
- drop btrfs_key_type(), which was dropped upstream by
962a298f3511 ("btrfs: kill the key type accessor helpers") ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
fs/btrfs/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/xattr.c b/fs/btrfs/xattr.c
index 42c6b2c..0e10de6 100644
--- a/fs/btrfs/xattr.c
+++ b/fs/btrfs/xattr.c
@@ -307,8 +307,10 @@ ssize_t btrfs_listxattr(struct dentry *dentry, char
*buffer, size_t size)
/* check to make sure this item is what we want */
if (found_key.objectid != key.objectid)
break;
- if (btrfs_key_type(_key) != BTRFS_XATTR_ITEM_KEY)
+ if (found_key.type > BTRFS_XATTR_ITEM_KEY)
break;
+ if (found_key.type < BTRFS_XATTR_ITEM_KEY)
+ goto next;
di = btrfs_item_ptr(leaf, slot, struct btrfs_dir_item);
if (verify_dir_item(root, leaf, di))
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 58/86] x86/cpu: Call verify_cpu() after having entered long mode too
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 04633df0c43d710e5f696b06539c100898678235 upstream. When we get loaded by a 64-bit bootloader, kernel entry point is startup_64 in head_64.S. We don't trust any and all bootloaders because some will fiddle with CPU configuration so we go ahead and massage each CPU into sanity again. For example, some dell BIOSes have this XD disable feature which set IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround for other OSes but Linux sure doesn't need it. A similar thing is present in the Surface 3 firmware - see https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit only on the BSP: # rdmsr -a 0x1a0 400850089 850089 850089 850089 I know, right?! There's not even an off switch in there. So fix all those cases by sanitizing the 64-bit entry point too. For that, make verify_cpu() callable in 64-bit mode also. Requested-and-debugged-by: "H. Peter Anvin" Reported-and-tested-by: Bastien Nocera Signed-off-by: Borislav Petkov Cc: Matt Fleming Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email...@alien8.de Signed-off-by: Thomas Gleixner Signed-off-by: Kamal Mostafa --- arch/x86/kernel/head_64.S| 8 arch/x86/kernel/verify_cpu.S | 12 +++- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index a2dc0ad..761fd69 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -65,6 +65,9 @@ startup_64: * tables and then reload them. */ + /* Sanitize CPU configuration */ + call verify_cpu + /* * Compute the delta between the address I am compiled to run at and the * address I am actually running at. @@ -174,6 +177,9 @@ ENTRY(secondary_startup_64) * after the boot processor executes this code. */ + /* Sanitize CPU configuration */ + call verify_cpu + movq$(init_level4_pgt - __START_KERNEL_map), %rax 1: @@ -288,6 +294,8 @@ ENTRY(secondary_startup_64) pushq %rax# target address in negative space lretq +#include "verify_cpu.S" + #ifdef CONFIG_HOTPLUG_CPU /* * Boot CPU0 entry point. It's called from play_dead(). Everything has been set diff --git a/arch/x86/kernel/verify_cpu.S b/arch/x86/kernel/verify_cpu.S index b9242ba..4cf401f 100644 --- a/arch/x86/kernel/verify_cpu.S +++ b/arch/x86/kernel/verify_cpu.S @@ -34,10 +34,11 @@ #include verify_cpu: - pushfl # Save caller passed flags - pushl $0 # Kill any dangerous flags - popfl + pushf # Save caller passed flags + push$0 # Kill any dangerous flags + popf +#ifndef __x86_64__ pushfl # standard way to check for cpuid popl%eax movl%eax,%ebx @@ -48,6 +49,7 @@ verify_cpu: popl%eax cmpl%eax,%ebx jz verify_cpu_no_longmode # cpu has no cpuid +#endif movl$0x0,%eax # See if cpuid 1 is implemented cpuid @@ -130,10 +132,10 @@ verify_cpu_sse_test: jmp verify_cpu_sse_test # try again verify_cpu_no_longmode: - popfl # Restore caller passed flags + popf# Restore caller passed flags movl $1,%eax ret verify_cpu_sse_ok: - popfl # Restore caller passed flags + popf# Restore caller passed flags xorl %eax, %eax ret -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 56/86] proc: actually make proc_fd_permission() thread-friendly
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Oleg Nesterov
commit 54708d2858e79a2bdda10bf8a20c80eb96c20613 upstream.
The commit 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
fixed the access to /proc/self/fd from sub-threads, but introduced another
problem: a sub-thread can't access /proc//fd/ or /proc/thread-self/fd
if generic_permission() fails.
Change proc_fd_permission() to check same_thread_group(pid_task(), current).
Fixes: 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
Reported-by: "Jin, Yihua"
Signed-off-by: Oleg Nesterov
Cc: "Eric W. Biederman"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Kamal Mostafa
---
fs/proc/fd.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 985ea88..c06a1f9 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -283,11 +283,19 @@ static struct dentry *proc_lookupfd(struct inode *dir,
struct dentry *dentry,
*/
int proc_fd_permission(struct inode *inode, int mask)
{
- int rv = generic_permission(inode, mask);
+ struct task_struct *p;
+ int rv;
+
+ rv = generic_permission(inode, mask);
if (rv == 0)
- return 0;
- if (task_tgid(current) == proc_pid(inode))
+ return rv;
+
+ rcu_read_lock();
+ p = pid_task(proc_pid(inode), PIDTYPE_PID);
+ if (p && same_thread_group(p, current))
rv = 0;
+ rcu_read_unlock();
+
return rv;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 60/86] Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Filipe Manana
commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.
If we are using the NO_HOLES feature, we have a tiny time window when
running delalloc for a nodatacow inode where we can race with a concurrent
link or xattr add operation leading to a BUG_ON.
This happens because at run_delalloc_nocow() we end up casting a leaf item
of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
file extent item (struct btrfs_file_extent_item) and then analyse its
extent type field, which won't match any of the expected extent types
(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
explicit BUG_ON(1).
The following sequence diagram shows how the race happens when running a
no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
neighbour leafs:
Leaf X (has N items)Leaf Y
[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ]
slot N - 2 slot N - 1 slot 0
(Note the implicit hole for inode 257 regarding the [0, 8K[ range)
CPU 1 CPU 2
run_dealloc_nocow()
btrfs_lookup_file_extent()
--> searches for a key with value
(257 EXTENT_DATA 4096) in the
fs/subvol tree
--> returns us a path with
path->nodes[0] == leaf X and
path->slots[0] == N
because path->slots[0] is >=
btrfs_header_nritems(leaf X), it
calls btrfs_next_leaf()
btrfs_next_leaf()
--> releases the path
hard link added to our inode,
with key (257 INODE_REF 500)
added to the end of leaf X,
so leaf X now has N + 1 keys
--> searches for the key
(257 INODE_REF 256), because
it was the last key in leaf X
before it released the path,
with path->keep_locks set to 1
--> ends up at leaf X again and
it verifies that the key
(257 INODE_REF 256) is no longer
the last key in the leaf, so it
returns with path->nodes[0] ==
leaf X and path->slots[0] == N,
pointing to the new item with
key (257 INODE_REF 500)
the loop iteration of run_dealloc_nocow()
does not break out the loop and continues
because the key referenced in the path
at path->nodes[0] and path->slots[0] is
for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
and its offset (500) is less then our delalloc
range's end (8192)
the item pointed by the path, an inode reference item,
is (incorrectly) interpreted as a file extent item and
we get an invalid extent type, leading to the BUG_ON(1):
if (extent_type == BTRFS_FILE_EXTENT_REG ||
extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
(...)
} else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
(...)
} else {
BUG_ON(1)
}
The same can happen if a xattr is added concurrently and ends up having
a key with an offset smaller then the delalloc's range end.
So fix this by skipping keys with a type smaller than
BTRFS_EXTENT_DATA_KEY.
Signed-off-by: Filipe Manana
Signed-off-by: Kamal Mostafa
---
fs/btrfs/inode.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 160471f..e2319b2 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1207,8 +1207,14 @@ next_slot:
num_bytes = 0;
btrfs_item_key_to_cpu(leaf, _key, path->slots[0]);
- if (found_key.objectid > ino ||
- found_key.type > BTRFS_EXTENT_DATA_KEY ||
+ if (found_key.objectid > ino)
+ break;
+ if (WARN_ON_ONCE(found_key.objectid < ino) ||
+ found_key.type < BTRFS_EXTENT_DATA_KEY) {
+ path->slots[0]++;
+ goto next_slot;
+ }
+ if (found_key.type > BTRFS_EXTENT_DATA_KEY ||
found_key.offset > end)
break;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
لطفا به ما کمک اسپم مبارزه با
مشترک عزیز ارزش، با توجه به شکایات اسپم از کاربران ایمیل در سیستم وب سایت پست الکترونیکی ما، تحقیقات ما نشان می دهد که آدرس ایمیل خود را در سیستم وب ایمیل ما به خطر بیافتد. به عنوان یک نتیجه، نام کاربری شما غیرفعال خواهد شد اگر شما به ما ارسال کنید مورد نیاز اطلاعات بلافاصله برای پیکر بندی دوباره. اطلاعات مورد نیاز: .. شما نام کامل: ... آدرس ایمیل:. رمز عبور:.. تکرار کلمه عبور: ... عدم پاسخگویی بلافاصله در معرض دسترسی ایمیل خود را به خطر امنیتی از کد منبع ما بی درنگ نشانی ایمیل شما آسیب پذیر به اسپم. لطفا درک کنند که این یک اقدام امنیتی در نظر گرفته شده برای کمک به محافظت از شما و خود را است صندوق پستی. با تشکر از شما برای استفاده از سرویس ایمیل تحت وب اینترنتی ما. تیم پشتیبانی مرکز -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 66/86] KVM: x86: work around infinite loop in microcode when #AC is delivered
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Eric Northup
commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.
It was found that a guest can DoS a host by triggering an infinite
stream of "alignment check" (#AC) exceptions. This causes the
microcode to enter an infinite loop where the core never receives
another interrupt. The host kernel panics pretty quickly due to the
effects (CVE-2015-5307).
Signed-off-by: Eric Northup
Signed-off-by: Paolo Bonzini
Signed-off-by: Kamal Mostafa
---
arch/x86/include/uapi/asm/svm.h | 1 +
arch/x86/kvm/svm.c | 8
arch/x86/kvm/vmx.c | 5 -
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
index b5d7640..8a4add8 100644
--- a/arch/x86/include/uapi/asm/svm.h
+++ b/arch/x86/include/uapi/asm/svm.h
@@ -100,6 +100,7 @@
{ SVM_EXIT_EXCP_BASE + UD_VECTOR, "UD excp" }, \
{ SVM_EXIT_EXCP_BASE + PF_VECTOR, "PF excp" }, \
{ SVM_EXIT_EXCP_BASE + NM_VECTOR, "NM excp" }, \
+ { SVM_EXIT_EXCP_BASE + AC_VECTOR, "AC excp" }, \
{ SVM_EXIT_EXCP_BASE + MC_VECTOR, "MC excp" }, \
{ SVM_EXIT_INTR,"interrupt" }, \
{ SVM_EXIT_NMI, "nmi" }, \
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index fa8296f..fe3f4b8 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1103,6 +1103,7 @@ static void init_vmcb(struct vcpu_svm *svm)
set_exception_intercept(svm, PF_VECTOR);
set_exception_intercept(svm, UD_VECTOR);
set_exception_intercept(svm, MC_VECTOR);
+ set_exception_intercept(svm, AC_VECTOR);
set_intercept(svm, INTERCEPT_INTR);
set_intercept(svm, INTERCEPT_NMI);
@@ -1765,6 +1766,12 @@ static int ud_interception(struct vcpu_svm *svm)
return 1;
}
+static int ac_interception(struct vcpu_svm *svm)
+{
+ kvm_queue_exception_e(>vcpu, AC_VECTOR, 0);
+ return 1;
+}
+
static void svm_fpu_activate(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
@@ -3281,6 +3288,7 @@ static int (*const svm_exit_handlers[])(struct vcpu_svm
*svm) = {
[SVM_EXIT_EXCP_BASE + PF_VECTOR]= pf_interception,
[SVM_EXIT_EXCP_BASE + NM_VECTOR]= nm_interception,
[SVM_EXIT_EXCP_BASE + MC_VECTOR]= mc_interception,
+ [SVM_EXIT_EXCP_BASE + AC_VECTOR]= ac_interception,
[SVM_EXIT_INTR] = intr_interception,
[SVM_EXIT_NMI] = nmi_interception,
[SVM_EXIT_SMI] = nop_on_interception,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4b7094e..380ba0c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1388,7 +1388,7 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
u32 eb;
eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
-(1u << NM_VECTOR) | (1u << DB_VECTOR);
+(1u << NM_VECTOR) | (1u << DB_VECTOR) | (1u << AC_VECTOR);
if ((vcpu->guest_debug &
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
@@ -4823,6 +4823,9 @@ static int handle_exception(struct kvm_vcpu *vcpu)
return handle_rmode_exception(vcpu, ex_no, error_code);
switch (ex_no) {
+ case AC_VECTOR:
+ kvm_queue_exception_e(vcpu, AC_VECTOR, error_code);
+ return 1;
case DB_VECTOR:
dr6 = vmcs_readl(EXIT_QUALIFICATION);
if (!(vcpu->guest_debug &
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 65/86] KVM: x86: Defining missing x86 vectors
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Nadav Amit commit c9cdd085bb75226879fd468b88e2e7eb467325b7 upstream. Defining XE, XM and VE vector numbers. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [ kamal: 3.13-stable prereq ] Signed-off-by: Kamal Mostafa --- arch/x86/include/uapi/asm/kvm.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index d3a8778..d7dcef5 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -23,7 +23,10 @@ #define GP_VECTOR 13 #define PF_VECTOR 14 #define MF_VECTOR 16 +#define AC_VECTOR 17 #define MC_VECTOR 18 +#define XM_VECTOR 19 +#define VE_VECTOR 20 /* Select x86 specific features in */ #define __KVM_HAVE_PIT -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 73/86] wm831x_power: Use IRQF_ONESHOT to request threaded IRQs
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Valentin Rothberg
commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream.
Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.
Fixes: b5874f33bbaf ("wm831x_power: Use genirq")
Signed-off-by: Valentin Rothberg
Signed-off-by: Sebastian Reichel
Signed-off-by: Kamal Mostafa
---
drivers/power/wm831x_power.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 3bed2f5..3ccadf6 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -567,7 +567,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "SYSLO"));
ret = request_threaded_irq(irq, NULL, wm831x_syslo_irq,
- IRQF_TRIGGER_RISING, "System power low",
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "System
power low",
power);
if (ret != 0) {
dev_err(>dev, "Failed to request SYSLO IRQ %d: %d\n",
@@ -577,7 +577,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "PWR SRC"));
ret = request_threaded_irq(irq, NULL, wm831x_pwr_src_irq,
- IRQF_TRIGGER_RISING, "Power source",
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "Power
source",
power);
if (ret != 0) {
dev_err(>dev, "Failed to request PWR SRC IRQ %d: %d\n",
@@ -590,7 +590,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
platform_get_irq_byname(pdev,
wm831x_bat_irqs[i]));
ret = request_threaded_irq(irq, NULL, wm831x_bat_irq,
- IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
wm831x_bat_irqs[i],
power);
if (ret != 0) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 69/86] FS-Cache: Increase reference of parent after registering, netfs success
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Kinglong Mee
commit 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 upstream.
If netfs exist, fscache should not increase the reference of parent's
usage and n_children, otherwise, never be decreased.
v2: thanks David's suggest,
move increasing reference of parent if success
use kmem_cache_free() freeing primary_index directly
v3: don't move "netfs->primary_index->parent = _fsdef_index;"
Signed-off-by: Kinglong Mee
Signed-off-by: David Howells
Signed-off-by: Al Viro
Signed-off-by: Kamal Mostafa
---
fs/fscache/netfs.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/fscache/netfs.c b/fs/fscache/netfs.c
index 989f394..73e0333 100644
--- a/fs/fscache/netfs.c
+++ b/fs/fscache/netfs.c
@@ -47,9 +47,6 @@ int __fscache_register_netfs(struct fscache_netfs *netfs)
netfs->primary_index->netfs_data= netfs;
netfs->primary_index->flags = 1 << FSCACHE_COOKIE_ENABLED;
- atomic_inc(>primary_index->parent->usage);
- atomic_inc(>primary_index->parent->n_children);
-
spin_lock_init(>primary_index->lock);
INIT_HLIST_HEAD(>primary_index->backing_objects);
@@ -62,6 +59,9 @@ int __fscache_register_netfs(struct fscache_netfs *netfs)
goto already_registered;
}
+ atomic_inc(>primary_index->parent->usage);
+ atomic_inc(>primary_index->parent->n_children);
+
list_add(>link, _netfs_list);
ret = 0;
@@ -72,8 +72,7 @@ already_registered:
up_write(_addremove_sem);
if (ret < 0) {
- netfs->primary_index->parent = NULL;
- __fscache_cookie_put(netfs->primary_index);
+ kmem_cache_free(fscache_cookie_jar, netfs->primary_index);
netfs->primary_index = NULL;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 72/86] binfmt_elf: Don't clobber passed executable's file header
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: "Maciej W. Rozycki"
commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream.
Do not clobber the buffer space passed from `search_binary_handler' and
originally preloaded by `prepare_binprm' with the executable's file
header by overwriting it with its interpreter's file header. Instead
keep the buffer space intact and directly use the data structure locally
allocated for the interpreter's file header, fixing a bug introduced in
2.1.14 with loadable module support (linux-mips.org commit beb11695
[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
Adjust the amount of data read from the interpreter's file accordingly.
This was not an issue before loadable module support, because back then
`load_elf_binary' was executed only once for a given ELF executable,
whether the function succeeded or failed.
With loadable module support supported and enabled, upon a failure of
`load_elf_binary' -- which may for example be caused by architecture
code rejecting an executable due to a missing hardware feature requested
in the file header -- a module load is attempted and then the function
reexecuted by `search_binary_handler'. With the executable's file
header replaced with its interpreter's file header the executable can
then be erroneously accepted in this subsequent attempt.
Signed-off-by: Maciej W. Rozycki
Signed-off-by: Al Viro
Signed-off-by: Kamal Mostafa
---
fs/binfmt_elf.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 509e7549..2a1c31a 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -682,16 +682,16 @@ static int load_elf_binary(struct linux_binprm *bprm)
*/
would_dump(bprm, interpreter);
- retval = kernel_read(interpreter, 0, bprm->buf,
-BINPRM_BUF_SIZE);
- if (retval != BINPRM_BUF_SIZE) {
+ /* Get the exec headers */
+ retval = kernel_read(interpreter, 0,
+(void *)>interp_elf_ex,
+sizeof(loc->interp_elf_ex));
+ if (retval != sizeof(loc->interp_elf_ex)) {
if (retval >= 0)
retval = -EIO;
goto out_free_dentry;
}
- /* Get the exec headers */
- loc->interp_elf_ex = *((struct elfhdr *)bprm->buf);
break;
}
elf_ppnt++;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 78/86] ipv6: fix tunnel error handling
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: =?UTF-8?q?Michal=20Kube=C4=8Dek?=
commit ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d upstream.
Both tunnel6_protocol and tunnel46_protocol share the same error
handler, tunnel6_err(), which traverses through tunnel6_handlers list.
For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g.
in tunnel46_rcv(). Current code can generate an ICMPv6 error message
with an IPv4 packet embedded in it.
Fixes: 73d605d1abbd ("[IPSEC]: changing API of xfrm6_tunnel_register")
Signed-off-by: Michal Kubecek
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/ipv6/tunnel6.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/tunnel6.c b/net/ipv6/tunnel6.c
index 4b0f50d..ebcbb3c 100644
--- a/net/ipv6/tunnel6.c
+++ b/net/ipv6/tunnel6.c
@@ -147,6 +147,16 @@ static void tunnel6_err(struct sk_buff *skb, struct
inet6_skb_parm *opt,
break;
}
+static void tunnel46_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
+u8 type, u8 code, int offset, __be32 info)
+{
+ struct xfrm6_tunnel *handler;
+
+ for_each_tunnel_rcu(tunnel46_handlers, handler)
+ if (!handler->err_handler(skb, opt, type, code, offset, info))
+ break;
+}
+
static const struct inet6_protocol tunnel6_protocol = {
.handler= tunnel6_rcv,
.err_handler= tunnel6_err,
@@ -155,7 +165,7 @@ static const struct inet6_protocol tunnel6_protocol = {
static const struct inet6_protocol tunnel46_protocol = {
.handler= tunnel46_rcv,
- .err_handler= tunnel6_err,
+ .err_handler= tunnel46_err,
.flags = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 68/86] drm/ast: Initialized data needed to map fbdev memory
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Egbert Eich
commit 28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0 upstream.
Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.
Requested-by: Benjamin Herrenschmidt
Signed-off-by: Egbert Eich
[pulled from SuSE tree by me - airlied]
Signed-off-by: Dave Airlie
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_fb.c | 7 +++
drivers/gpu/drm/ast/ast_main.c | 1 +
drivers/gpu/drm/ast/ast_mode.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9833a1b..3fc1223 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -296,6 +296,7 @@ int ast_framebuffer_init(struct drm_device *dev,
int ast_fbdev_init(struct drm_device *dev);
void ast_fbdev_fini(struct drm_device *dev);
void ast_fbdev_set_suspend(struct drm_device *dev, int state);
+void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr);
struct ast_bo {
struct ttm_buffer_object bo;
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f..b55b6b1 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -367,3 +367,10 @@ void ast_fbdev_set_suspend(struct drm_device *dev, int
state)
fb_set_suspend(ast->fbdev->helper.fbdev, state);
}
+
+void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr)
+{
+ ast->fbdev->helper.fbdev->fix.smem_start =
+ ast->fbdev->helper.fbdev->apertures->ranges[0].base + gpu_addr;
+ ast->fbdev->helper.fbdev->fix.smem_len = ast->vram_size - gpu_addr;
+}
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 4e09386..45bb8e8 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -360,6 +360,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
dev->mode_config.min_height = 0;
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = pci_resource_start(ast->dev->pdev, 0);
if (ast->chip == AST2100 ||
ast->chip == AST2200 ||
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e8f6418..f3a54ad 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -509,6 +509,8 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >kmap);
if (ret)
DRM_ERROR("failed to kmap fbcon\n");
+ else
+ ast_fbdev_set_base(ast, gpu_addr);
}
ast_bo_unreserve(bo);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 62/86] scsi_sysfs: Fix queue_ramp_up_period return code
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let me know. -- From: Peter Oberparleiter commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream. Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period returns the value of that number instead of the number of bytes written. This behavior can confuse programs expecting POSIX write() semantics. Fix this by returning the number of bytes written instead. Signed-off-by: Peter Oberparleiter Reviewed-by: Hannes Reinecke Reviewed-by: Matthew R. Ochs Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Kamal Mostafa --- drivers/scsi/scsi_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 8ff62c2..825f237 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -873,7 +873,7 @@ sdev_store_queue_ramp_up_period(struct device *dev, return -EINVAL; sdev->queue_ramp_up_period = msecs_to_jiffies(period); - return period; + return count; } static struct device_attribute sdev_attr_queue_ramp_up_period = -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] serial: xuartps: Spliting the ISR into smaller routines.
Hi Navakishore, On 12/02/2015 12:32 AM, Nava kishore Manne wrote: > Yes I agree l see that no comments for your series of patches as of now... Reviewing Sören's patches are on my TODO list before the end of the week. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 71/86] FS-Cache: Handle a write to the page immediately beyond the EOF marker
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: David Howells
commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream.
Handle a write being requested to the page immediately beyond the EOF
marker on a cache object. Currently this gets an assertion failure in
CacheFiles because the EOF marker is used there to encode information about
a partial page at the EOF - which could lead to an unknown blank spot in
the file if we extend the file over it.
The problem is actually in fscache where we check the index of the page
being written against store_limit. store_limit is set to the number of
pages that we're allowed to store by fscache_set_store_limit() - which
means it's one more than the index of the last page we're allowed to store.
The problem is that we permit writing to a page with an index _equal_ to
the store limit - when we should reject that case.
Whilst we're at it, change the triggered assertion in CacheFiles to just
return -ENOBUFS instead.
The assertion failure looks something like this:
CacheFiles: Assertion failed
1000 < 7b1 is false
[ cut here ]
kernel BUG at fs/cachefiles/rdwr.c:962!
...
RIP: 0010:[] []
cachefiles_write_page+0x273/0x2d0 [cachefiles]
Signed-off-by: David Howells
Signed-off-by: Al Viro
[ kamal: backport to 3.13-stable: no __kernel_write(); thanks Ben H. ]
Signed-off-by: Kamal Mostafa
---
fs/cachefiles/rdwr.c | 79 +++-
fs/fscache/page.c| 2 +-
2 files changed, 42 insertions(+), 39 deletions(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index ebaff36..807e554 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -919,6 +919,15 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
cache = container_of(object->fscache.cache,
struct cachefiles_cache, cache);
+ pos = (loff_t)page->index << PAGE_SHIFT;
+
+ /* We mustn't write more data than we have, so we have to beware of a
+* partial page at EOF.
+*/
+ eof = object->fscache.store_limit_l;
+ if (pos >= eof)
+ goto error;
+
/* write the page to the backing filesystem and let it store it in its
* own time */
path.mnt = cache->mnt;
@@ -926,49 +935,43 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
file = dentry_open(, O_RDWR | O_LARGEFILE, cache->cache_cred);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
- } else {
- ret = -EIO;
- if (file->f_op->write) {
- pos = (loff_t) page->index << PAGE_SHIFT;
-
- /* we mustn't write more data than we have, so we have
-* to beware of a partial page at EOF */
- eof = object->fscache.store_limit_l;
- len = PAGE_SIZE;
- if (eof & ~PAGE_MASK) {
- ASSERTCMP(pos, <, eof);
- if (eof - pos < PAGE_SIZE) {
- _debug("cut short %llx to %llx",
- pos, eof);
- len = eof - pos;
- ASSERTCMP(pos + len, ==, eof);
- }
- }
+ goto error_2;
+ }
- data = kmap(page);
- file_start_write(file);
- old_fs = get_fs();
- set_fs(KERNEL_DS);
- ret = file->f_op->write(
- file, (const void __user *) data, len, );
- set_fs(old_fs);
- kunmap(page);
- file_end_write(file);
- if (ret != len)
- ret = -EIO;
+ len = PAGE_SIZE;
+ if (eof & ~PAGE_MASK) {
+ if (eof - pos < PAGE_SIZE) {
+ _debug("cut short %llx to %llx",
+ pos, eof);
+ len = eof - pos;
+ ASSERTCMP(pos + len, ==, eof);
}
- fput(file);
}
- if (ret < 0) {
- if (ret == -EIO)
- cachefiles_io_error_obj(
- object, "Write page to backing file failed");
- ret = -ENOBUFS;
- }
+ data = kmap(page);
+ file_start_write(file);
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = file->f_op->write(
+ file, (const void __user *) data, len, );
+ set_fs(old_fs);
+ kunmap(page);
+ fput(file);
+ if (ret != len)
+ goto error_eio;
+
+ _leave(" = 0");
+ return 0;
- _leave(" =
[PATCH v8 2/7] dmaengine: mxs: APBH DMA supports deep sleep mode
From: Huang Shijie
Deep Sleep Mode(dsm) turns off the power for APBH DMA module, DMA
need to be re-initialized when system resumed back.
Signed-off-by: Huang Shijie
Signed-off-by: Han Xu
---
drivers/dma/mxs-dma.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 60de352..eba51fc 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -693,7 +693,7 @@ static enum dma_status mxs_dma_tx_status(struct dma_chan
*chan,
return mxs_chan->status;
}
-static int __init mxs_dma_init(struct mxs_dma_engine *mxs_dma)
+static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
{
int ret;
@@ -835,6 +835,7 @@ static int __init mxs_dma_probe(struct platform_device
*pdev)
mxs_dma->pdev = pdev;
mxs_dma->dma_device.dev = >dev;
+ dev_set_drvdata(>dev, mxs_dma);
/* mxs_dma gets 65535 bytes maximum sg size */
mxs_dma->dma_device.dev->dma_parms = _dma->dma_parms;
@@ -872,9 +873,23 @@ static int __init mxs_dma_probe(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mxs_dma_pm_resume(struct device *dev)
+{
+ struct mxs_dma_engine *mxs_dma = dev_get_drvdata(dev);
+
+ return mxs_dma_init(mxs_dma);
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops mxs_dma_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, mxs_dma_pm_resume)
+};
+
static struct platform_driver mxs_dma_driver = {
.driver = {
.name = "mxs-dma",
+ .pm = _dma_pm_ops,
.of_match_table = mxs_dma_dt_ids,
},
.id_table = mxs_dma_ids,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 3/7] dmaengine: mxs: add i.MX7D APBH DMA support
From: Adrian Alonso
supports APBH DMA on i.MX7D by add extra clock clk_io
Signed-off-by: Fugang Duan
Signed-off-by: Adrian Alonso
Signed-off-by: Han Xu
---
drivers/dma/mxs-dma.c | 52 ---
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index eba51fc..3691b4a 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011-2015 Freescale Semiconductor, Inc. All Rights Reserved.
*
* Refer to drivers/dma/imx-sdma.c
*
@@ -28,7 +28,6 @@
#include
#include
#include
-
#include
#include "dmaengine.h"
@@ -135,6 +134,7 @@ enum mxs_dma_devtype {
enum mxs_dma_id {
IMX23_DMA,
IMX28_DMA,
+ IMX7D_DMA,
};
struct mxs_dma_engine {
@@ -142,6 +142,7 @@ struct mxs_dma_engine {
enum mxs_dma_devtypetype;
void __iomem*base;
struct clk *clk;
+ struct clk *clk_io;
struct dma_device dma_device;
struct device_dma_parametersdma_parms;
struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS];
@@ -167,6 +168,9 @@ static struct mxs_dma_type mxs_dma_types[] = {
}, {
.id = IMX28_DMA,
.type = MXS_DMA_APBX,
+ }, {
+ .id = IMX7D_DMA,
+ .type = MXS_DMA_APBH,
}
};
@@ -184,6 +188,9 @@ static const struct platform_device_id mxs_dma_ids[] = {
.name = "imx28-dma-apbx",
.driver_data = (kernel_ulong_t) _dma_types[3],
}, {
+ .name = "imx7d-dma-apbh",
+ .driver_data = (kernel_ulong_t) _dma_types[4],
+ }, {
/* end of list */
}
};
@@ -193,6 +200,7 @@ static const struct of_device_id mxs_dma_dt_ids[] = {
{ .compatible = "fsl,imx23-dma-apbx", .data = _dma_ids[1], },
{ .compatible = "fsl,imx28-dma-apbh", .data = _dma_ids[2], },
{ .compatible = "fsl,imx28-dma-apbx", .data = _dma_ids[3], },
+ { .compatible = "fsl,imx7d-dma-apbh", .data = _dma_ids[4], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
@@ -440,6 +448,13 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
if (ret)
goto err_clk;
+ /* enable the extra clk_io clock for i.MX7D */
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ ret = clk_prepare_enable(mxs_dma->clk_io);
+ if (ret)
+ goto err_clk_unprepare;
+ }
+
mxs_dma_reset_chan(chan);
dma_async_tx_descriptor_init(_chan->desc, chan);
@@ -450,6 +465,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
return 0;
+err_clk_unprepare:
+ clk_disable_unprepare(mxs_dma->clk);
err_clk:
free_irq(mxs_chan->chan_irq, mxs_dma);
err_irq:
@@ -471,6 +488,9 @@ static void mxs_dma_free_chan_resources(struct dma_chan
*chan)
dma_free_coherent(mxs_dma->dma_device.dev, CCW_BLOCK_SIZE,
mxs_chan->ccw, mxs_chan->ccw_phys);
+ if (mxs_dma->dev_id == IMX7D_DMA)
+ clk_disable_unprepare(mxs_dma->clk_io);
+
clk_disable_unprepare(mxs_dma->clk);
}
@@ -701,9 +721,15 @@ static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
if (ret)
return ret;
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ ret = clk_prepare_enable(mxs_dma->clk_io);
+ if (ret)
+ goto err_clk_bch;
+ }
+
ret = stmp_reset_block(mxs_dma->base);
if (ret)
- goto err_out;
+ goto err_clk_io;
/* enable apbh burst */
if (dma_is_apbh(mxs_dma)) {
@@ -717,7 +743,10 @@ static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
writel(MXS_DMA_CHANNELS_MASK << MXS_DMA_CHANNELS,
mxs_dma->base + HW_APBHX_CTRL1 + STMP_OFFSET_REG_SET);
-err_out:
+err_clk_io:
+ if (mxs_dma->dev_id == IMX7D_DMA)
+ clk_disable_unprepare(mxs_dma->clk_io);
+err_clk_bch:
clk_disable_unprepare(mxs_dma->clk);
return ret;
}
@@ -803,9 +832,18 @@ static int __init mxs_dma_probe(struct platform_device
*pdev)
if (IS_ERR(mxs_dma->base))
return PTR_ERR(mxs_dma->base);
- mxs_dma->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(mxs_dma->clk))
- return PTR_ERR(mxs_dma->clk);
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ mxs_dma->clk = devm_clk_get(>dev, "dma_apbh_bch");
+ if (IS_ERR(mxs_dma->clk))
+ return PTR_ERR(mxs_dma->clk);
+ mxs_dma->clk_io = devm_clk_get(>dev, "dma_apbh_io");
+ if (IS_ERR(mxs_dma->clk_io))
+ return PTR_ERR(mxs_dma->clk_io);
+
[PATCH v8 0/7] mtd: nand: gpmi: gpmi-nand DSM and bitflip support
v1 ---> v2 change the erased page bitflip threshold to ecc strength in bitflip patch v2 ---> v3 remove unnecessary function in mxs-dma change the log message when legacy_set_geometry failed fix the comment message for bitflip add comma for all field entries v3 ---> v4 code style change for indentation v4 ---> v5 split the DMA PM and i.MX7D support into two patches add more comments fix the DMA clock count mismatch issue for i.MX7D v5 ---> v6 add a sentinel entry for of_device_id to fix build error v6 ---> v7 add CONFIG_PM_SLEEP for GPMI/DMA PM code v7 ---> v8 remove empty line simplify mxs_dma_init return check Adrian Alonso (1): dmaengine: mxs: add i.MX7D APBH DMA support Han Xu (4): mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND mtd: nand: gpmi: add GPMI NAND support for i.MX7D mtd: nand: gpmi: correct bitflip for erased NAND page mtd: nand: gpmi: support NAND on i.MX6UL Huang Shijie (2): mtd: nand: gpmi: add gpmi dsm supend/resume support dmaengine: mxs: APBH DMA supports deep sleep mode drivers/dma/mxs-dma.c | 69 +++-- drivers/mtd/nand/gpmi-nand/bch-regs.h | 24 -- drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 15 +++- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 133 - drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 14 +++- 5 files changed, 214 insertions(+), 41 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 6/7] mtd: nand: gpmi: correct bitflip for erased NAND page
i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
bitflip number for erased NAND page. So for these two platform, set the
erase threshold to ecc_strength and if bitflip detected, GPMI driver will
correct the data to all 0xFF.
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/bch-regs.h | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 5 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +++-
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 5 -
4 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 53e58bc..a84d72b 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -30,7 +30,13 @@
#define BM_BCH_CTRL_COMPLETE_IRQ (1 << 0)
#define HW_BCH_STATUS0 0x0010
+
#define HW_BCH_MODE0x0020
+#define BP_BCH_MODE_ERASE_THRESHOLD0
+#define BM_BCH_MODE_ERASE_THRESHOLD(0xff << BP_BCH_MODE_ERASE_THRESHOLD)
+#define BF_BCH_MODE_ERASE_THRESHOLD(v) \
+ (((v) << BP_BCH_MODE_ERASE_THRESHOLD) & BM_BCH_MODE_ERASE_THRESHOLD)
+
#define HW_BCH_ENCODEPTR 0x0030
#define HW_BCH_DATAPTR 0x0040
#define HW_BCH_METAPTR 0x0050
@@ -125,4 +131,8 @@
)
#define HW_BCH_VERSION 0x0160
+#define HW_BCH_DEBUG1 0x0170
+#define BP_BCH_DEBUG1_ERASED_ZERO_COUNT0
+#define BM_BCH_DEBUG1_ERASED_ZERO_COUNT\
+ (0x1ff << BP_BCH_DEBUG1_ERASED_ZERO_COUNT)
#endif
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 1f26a79..0548d84 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -298,6 +298,11 @@ int bch_set_geometry(struct gpmi_nand_data *this)
| BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this),
r->bch_regs + HW_BCH_FLASH0LAYOUT1);
+ /* Set erase threshold to ecc_strength for mx6qp and mx7 */
+ if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+ writel(BF_BCH_MODE_ERASE_THRESHOLD(ecc_strength),
+ r->bch_regs + HW_BCH_MODE);
+
/* Set *all* chip selects to use layout 0. */
writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 9f67f0f..9dea56e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -71,6 +71,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6q = {
.max_chain_delay = 12,
};
+static const struct gpmi_devdata gpmi_devdata_imx6qp = {
+ .type = IS_MX6QP,
+ .bch_max_ecc_strength = 40,
+ .max_chain_delay = 12,
+};
+
static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
@@ -1010,6 +1016,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
{
struct gpmi_nand_data *this = chip->priv;
struct bch_geometry *nfc_geo = >bch_geometry;
+ void __iomem *bch_regs = this->resources.bch_regs;
void *payload_virt;
dma_addr_tpayload_phys;
void *auxiliary_virt;
@@ -1018,6 +1025,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
unsigned char *status;
unsigned int max_bitflips = 0;
int ret;
+ int flag = 0;
dev_dbg(this->dev, "page number is : %d\n", page);
ret = read_page_prepare(this, buf, nfc_geo->payload_size,
@@ -1050,9 +1058,16 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
- if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
+ if (*status == STATUS_GOOD)
continue;
+ if (*status == STATUS_ERASED) {
+ if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+ if (readl(bch_regs + HW_BCH_DEBUG1))
+ flag = 1;
+ continue;
+ }
+
if (*status == STATUS_UNCORRECTABLE) {
mtd->ecc_stats.failed++;
continue;
@@ -1081,6 +1096,10 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
nfc_geo->payload_size,
payload_virt, payload_phys);
+ /* if bitflip occurred in erased page, change data to all 0xff */
+ if (flag)
+ memset(buf, 0xff, nfc_geo->payload_size);
+
[PATCH v8 5/7] mtd: nand: gpmi: add GPMI NAND support for i.MX7D
support GPMI NAND on i.MX7D
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/bch-regs.h | 14 +++---
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 27 ++-
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 7 +--
4 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 05bb91f..53e58bc 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright 2008-2015 Freescale Semiconductor, Inc.
* Copyright 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -54,7 +54,7 @@
#define MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0 11
#define MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0 (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0)
#define BF_BCH_FLASH0LAYOUT0_ECC0(v, x)\
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0) \
& MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0) \
: (((v) << BP_BCH_FLASH0LAYOUT0_ECC0) \
@@ -65,7 +65,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14)
#define BF_BCH_FLASH0LAYOUT0_GF(v, x) \
- ((GPMI_IS_MX6(x) && ((v) == 14))\
+ (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14) \
& MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14) \
: 0 \
@@ -77,7 +77,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE \
(0x3ff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)
#define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(v, x) \
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \
: ((v) & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \
)
@@ -96,7 +96,7 @@
#define MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN 11
#define MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN)
#define BF_BCH_FLASH0LAYOUT1_ECCN(v, x)\
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN) \
& MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN) \
: (((v) << BP_BCH_FLASH0LAYOUT1_ECCN) \
@@ -107,7 +107,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14)
#define BF_BCH_FLASH0LAYOUT1_GF(v, x) \
- ((GPMI_IS_MX6(x) && ((v) == 14))\
+ (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14) \
& MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14) \
: 0 \
@@ -119,7 +119,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE \
(0x3ff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE)
#define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(v, x) \
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \
: ((v) & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \
)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 43fa16b..1f26a79 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -971,7 +971,8 @@ int gpmi_extra_init(struct gpmi_nand_data *this)
struct nand_chip *chip = >nand;
/* Enable the asynchronous EDO feature. */
- if (GPMI_IS_MX6(this) && chip->onfi_version) {
+ if ((GPMI_IS_MX6(this) || GPMI_IS_MX7(this)) &&
+ chip->onfi_version) {
int mode = onfi_get_async_timing_mode(chip);
/* We only support the timing mode 4 and
[PATCH v8 1/7] mtd: nand: gpmi: add gpmi dsm supend/resume support
From: Huang Shijie
i.MX6SX supports deep sleep mode(DSM) that may turn off GPMI/BCH power
during suspend, add gpmi nand suspend/resume function to release DMA
channel in suspend function and re-init GPMI/BCH controller during
resume function.
Although it is not necessary to restore GPMI/BCH registers value for
i.MX6QDL, the code doesn't distinguish different platforms to keep the
code simple.
Signed-off-by: Huang Shijie
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 47 +-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 5a9b696..ba5975f 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -2035,9 +2035,54 @@ static int gpmi_nand_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int gpmi_pm_suspend(struct device *dev)
+{
+ struct gpmi_nand_data *this = dev_get_drvdata(dev);
+
+ release_dma_channels(this);
+ return 0;
+}
+
+static int gpmi_pm_resume(struct device *dev)
+{
+ struct gpmi_nand_data *this = dev_get_drvdata(dev);
+ int ret;
+
+ ret = acquire_dma_channels(this);
+ if (ret < 0)
+ return ret;
+
+ /* re-init the GPMI registers */
+ this->flags &= ~GPMI_TIMING_INIT_OK;
+ ret = gpmi_init(this);
+ if (ret) {
+ dev_err(this->dev, "Error setting GPMI : %d\n", ret);
+ return ret;
+ }
+
+ /* re-init the BCH registers */
+ ret = bch_set_geometry(this);
+ if (ret) {
+ dev_err(this->dev, "Error setting BCH : %d\n", ret);
+ return ret;
+ }
+
+ /* re-init others */
+ gpmi_extra_init(this);
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops gpmi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(gpmi_pm_suspend, gpmi_pm_resume)
+};
+
static struct platform_driver gpmi_nand_driver = {
.driver = {
.name = "gpmi-nand",
+ .pm = _pm_ops,
.of_match_table = gpmi_nand_id_table,
},
.probe = gpmi_nand_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 81/86] mac80211: fix driver RSSI event calculations
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Johannes Berg
commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.
The ifmgd->ave_beacon_signal value cannot be taken as is for
comparisons, it must be divided by since it's represented
like that for better accuracy of the EWMA calculations. This
would lead to invalid driver RSSI events. Fix the used value.
Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
Signed-off-by: Johannes Berg
Signed-off-by: Kamal Mostafa
---
net/mac80211/mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0c32180..a2df2c4 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2852,7 +2852,7 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
if (ifmgd->rssi_min_thold != ifmgd->rssi_max_thold &&
ifmgd->count_beacon_signal >= IEEE80211_SIGNAL_AVE_MIN_COUNT) {
- int sig = ifmgd->ave_beacon_signal;
+ int sig = ifmgd->ave_beacon_signal / 16;
int last_sig = ifmgd->last_ave_beacon_signal;
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 4/7] mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND
By default NAND driver will choose the highest ecc strength that oob
could contain, in this case, for some 8K+744 NAND flash, the ecc
strength will be up to 52bit, which beyonds the i.MX6QDL BCH capability
(40bit).
This patch allows the NAND driver try to use minimum required ecc
strength if it failed to use the highest ecc, even without explicitly
claiming "fsl,use-minimum-ecc" in dts.
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index ba5975f..298c1d1 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -136,7 +136,7 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data
*this)
*
* We may have available oob space in this case.
*/
-static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this)
+static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
{
struct bch_geometry *geo = >bch_geometry;
struct mtd_info *mtd = >mtd;
@@ -145,7 +145,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
unsigned int block_mark_bit_offset;
if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
- return false;
+ return -EINVAL;
switch (chip->ecc_step_ds) {
case SZ_512:
@@ -158,19 +158,19 @@ static bool set_geometry_by_ecc_info(struct
gpmi_nand_data *this)
dev_err(this->dev,
"unsupported nand chip. ecc bits : %d, ecc size : %d\n",
chip->ecc_strength_ds, chip->ecc_step_ds);
- return false;
+ return -EINVAL;
}
geo->ecc_chunk_size = chip->ecc_step_ds;
geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
if (!gpmi_check_ecc(this))
- return false;
+ return -EINVAL;
/* Keep the C >= O */
if (geo->ecc_chunk_size < mtd->oobsize) {
dev_err(this->dev,
"unsupported nand chip. ecc size: %d, oob size : %d\n",
chip->ecc_step_ds, mtd->oobsize);
- return false;
+ return -EINVAL;
}
/* The default value, see comment in the legacy_set_geometry(). */
@@ -242,7 +242,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
+ ALIGN(geo->ecc_chunk_count, 4);
if (!this->swap_block_mark)
- return true;
+ return 0;
/* For bit swap. */
block_mark_bit_offset = mtd->writesize * 8 -
@@ -251,7 +251,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
geo->block_mark_byte_offset = block_mark_bit_offset / 8;
geo->block_mark_bit_offset = block_mark_bit_offset % 8;
- return true;
+ return 0;
}
static int legacy_set_geometry(struct gpmi_nand_data *this)
@@ -285,7 +285,8 @@ static int legacy_set_geometry(struct gpmi_nand_data *this)
geo->ecc_strength = get_ecc_strength(this);
if (!gpmi_check_ecc(this)) {
dev_err(this->dev,
- "required ecc strength of the NAND chip: %d is not
supported by the GPMI controller (%d)\n",
+ "ecc strength: %d cannot be supported by the controller
(%d)\n"
+ "try to use minimum ecc strength that NAND chip
required\n",
geo->ecc_strength,
this->devdata->bch_max_ecc_strength);
return -EINVAL;
@@ -366,10 +367,11 @@ static int legacy_set_geometry(struct gpmi_nand_data
*this)
int common_nfc_set_geometry(struct gpmi_nand_data *this)
{
- if (of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc")
- && set_geometry_by_ecc_info(this))
- return 0;
- return legacy_set_geometry(this);
+ if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc"))
+ || legacy_set_geometry(this))
+ return set_geometry_by_ecc_info(this);
+
+ return 0;
}
struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 7/7] mtd: nand: gpmi: support NAND on i.MX6UL
support GPMI NAND on i.MX6UL
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 4 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 9dea56e..41d9012 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -89,6 +89,12 @@ static const struct gpmi_devdata gpmi_devdata_imx7d = {
.max_chain_delay = 12,
};
+static const struct gpmi_devdata gpmi_devdata_imx6ul = {
+ .type = IS_MX6UL,
+ .bch_max_ecc_strength = 40,
+ .max_chain_delay = 12,
+};
+
static irqreturn_t bch_irq(int irq, void *cookie)
{
struct gpmi_nand_data *this = cookie;
@@ -2015,6 +2021,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = _devdata_imx6sx,
}, {
+ .compatible = "fsl,imx6ul-gpmi-nand",
+ .data = (void *)_devdata_imx6ul,
+ }, {
.compatible = "fsl,imx7d-gpmi-nand",
.data = (void *)_devdata_imx7d,
}, { /* sentinel */ }
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 149a442..331f98e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -126,6 +126,7 @@ enum gpmi_type {
IS_MX6QP,
IS_MX6SX,
IS_MX7D,
+ IS_MX6UL,
};
struct gpmi_devdata {
@@ -310,8 +311,9 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
#define GPMI_IS_MX6QP(x) ((x)->devdata->type == IS_MX6QP)
#define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
#define GPMI_IS_MX7D(x)((x)->devdata->type == IS_MX7D)
+#define GPMI_IS_MX6UL(x) ((x)->devdata->type == IS_MX6UL)
#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6QP(x)\
- || GPMI_IS_MX6SX(x))
+ || GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
#define GPMI_IS_MX7(x) (GPMI_IS_MX7D(x))
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 70/86] FS-Cache: Don't override netfs's primary_index if registering failed
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Kinglong Mee
commit b130ed5998e62879a66bad08931a2b5e832da95c upstream.
Only override netfs->primary_index when registering success.
Signed-off-by: Kinglong Mee
Signed-off-by: David Howells
Signed-off-by: Al Viro
Signed-off-by: Kamal Mostafa
---
fs/fscache/netfs.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/fs/fscache/netfs.c b/fs/fscache/netfs.c
index 73e0333..96e48c6 100644
--- a/fs/fscache/netfs.c
+++ b/fs/fscache/netfs.c
@@ -22,6 +22,7 @@ static LIST_HEAD(fscache_netfs_list);
int __fscache_register_netfs(struct fscache_netfs *netfs)
{
struct fscache_netfs *ptr;
+ struct fscache_cookie *cookie;
int ret;
_enter("{%s}", netfs->name);
@@ -29,26 +30,25 @@ int __fscache_register_netfs(struct fscache_netfs *netfs)
INIT_LIST_HEAD(>link);
/* allocate a cookie for the primary index */
- netfs->primary_index =
- kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL);
+ cookie = kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL);
- if (!netfs->primary_index) {
+ if (!cookie) {
_leave(" = -ENOMEM");
return -ENOMEM;
}
/* initialise the primary index cookie */
- atomic_set(>primary_index->usage, 1);
- atomic_set(>primary_index->n_children, 0);
- atomic_set(>primary_index->n_active, 1);
+ atomic_set(>usage, 1);
+ atomic_set(>n_children, 0);
+ atomic_set(>n_active, 1);
- netfs->primary_index->def = _fsdef_netfs_def;
- netfs->primary_index->parent= _fsdef_index;
- netfs->primary_index->netfs_data= netfs;
- netfs->primary_index->flags = 1 << FSCACHE_COOKIE_ENABLED;
+ cookie->def = _fsdef_netfs_def;
+ cookie->parent = _fsdef_index;
+ cookie->netfs_data = netfs;
+ cookie->flags = 1 << FSCACHE_COOKIE_ENABLED;
- spin_lock_init(>primary_index->lock);
- INIT_HLIST_HEAD(>primary_index->backing_objects);
+ spin_lock_init(>lock);
+ INIT_HLIST_HEAD(>backing_objects);
/* check the netfs type is not already present */
down_write(_addremove_sem);
@@ -59,9 +59,10 @@ int __fscache_register_netfs(struct fscache_netfs *netfs)
goto already_registered;
}
- atomic_inc(>primary_index->parent->usage);
- atomic_inc(>primary_index->parent->n_children);
+ atomic_inc(>parent->usage);
+ atomic_inc(>parent->n_children);
+ netfs->primary_index = cookie;
list_add(>link, _netfs_list);
ret = 0;
@@ -71,10 +72,8 @@ int __fscache_register_netfs(struct fscache_netfs *netfs)
already_registered:
up_write(_addremove_sem);
- if (ret < 0) {
- kmem_cache_free(fscache_cookie_jar, netfs->primary_index);
- netfs->primary_index = NULL;
- }
+ if (ret < 0)
+ kmem_cache_free(fscache_cookie_jar, cookie);
_leave(" = %d", ret);
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 79/86] perf trace: Fix documentation for -i
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Peter Feiner
commit 956959f6b7a982b2e789a7a8fa1de437074a5eb9 upstream.
The -i flag was incorrectly listed as a short flag for --no-inherit. It
should have only been listed as a short flag for --input.
This documentation error has existed since the --input flag was
introduced in 6810fc915f7a89d8134edb3996dbbf8eac386c26 (perf trace: Add
option to analyze events in a file versus live).
Signed-off-by: Peter Feiner
Cc: David Ahern
Link:
http://lkml.kernel.org/r/1446657706-14518-1-git-send-email-pfei...@google.com
Fixes: 6810fc915f7a ("perf trace: Add option to analyze events in a file versus
live")
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Kamal Mostafa
---
tools/perf/Documentation/perf-trace.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-trace.txt
b/tools/perf/Documentation/perf-trace.txt
index fae38d9..65d6a7a 100644
--- a/tools/perf/Documentation/perf-trace.txt
+++ b/tools/perf/Documentation/perf-trace.txt
@@ -59,7 +59,6 @@ OPTIONS
--verbose=::
Verbosity level.
--i::
--no-inherit::
Child tasks do not inherit counters.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 67/86] KVM: svm: unconditionally intercept #DB
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Paolo Bonzini
commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.
This is needed to avoid the possibility that the guest triggers
an infinite stream of #DB exceptions (CVE-2015-8104).
VMX is not affected: because it does not save DR6 in the VMCS,
it already intercepts #DB unconditionally.
Reported-by: Jan Beulich
Signed-off-by: Paolo Bonzini
Signed-off-by: Kamal Mostafa
---
arch/x86/kvm/svm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index fe3f4b8..853897c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1104,6 +1104,7 @@ static void init_vmcb(struct vcpu_svm *svm)
set_exception_intercept(svm, UD_VECTOR);
set_exception_intercept(svm, MC_VECTOR);
set_exception_intercept(svm, AC_VECTOR);
+ set_exception_intercept(svm, DB_VECTOR);
set_intercept(svm, INTERCEPT_INTR);
set_intercept(svm, INTERCEPT_NMI);
@@ -1640,20 +1641,13 @@ static void svm_set_segment(struct kvm_vcpu *vcpu,
mark_dirty(svm->vmcb, VMCB_SEG);
}
-static void update_db_bp_intercept(struct kvm_vcpu *vcpu)
+static void update_bp_intercept(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
- clr_exception_intercept(svm, DB_VECTOR);
clr_exception_intercept(svm, BP_VECTOR);
- if (svm->nmi_singlestep)
- set_exception_intercept(svm, DB_VECTOR);
-
if (vcpu->guest_debug & KVM_GUESTDBG_ENABLE) {
- if (vcpu->guest_debug &
- (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))
- set_exception_intercept(svm, DB_VECTOR);
if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
set_exception_intercept(svm, BP_VECTOR);
} else
@@ -1731,7 +1725,6 @@ static int db_interception(struct vcpu_svm *svm)
if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP))
svm->vmcb->save.rflags &=
~(X86_EFLAGS_TF | X86_EFLAGS_RF);
- update_db_bp_intercept(>vcpu);
}
if (svm->vcpu.guest_debug &
@@ -3677,7 +3670,6 @@ static int enable_nmi_window(struct kvm_vcpu *vcpu)
*/
svm->nmi_singlestep = true;
svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
- update_db_bp_intercept(vcpu);
return 0;
}
@@ -4279,7 +4271,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.vcpu_load = svm_vcpu_load,
.vcpu_put = svm_vcpu_put,
- .update_db_bp_intercept = update_db_bp_intercept,
+ .update_db_bp_intercept = update_bp_intercept,
.get_msr = svm_get_msr,
.set_msr = svm_set_msr,
.get_segment_base = svm_get_segment_base,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 64/86] storvsc: Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: "K. Y. Srinivasan"
commit 8cf308e1225f5f93575f03cc4dbef24516fa81c9 upstream.
Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
tags. Without this, the qlogic driver doesn't work properly with storvsc.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: James Bottomley
Signed-off-by: Kamal Mostafa
---
drivers/scsi/storvsc_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3bb6646..f9da66f 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1610,8 +1610,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
vm_srb->win8_extension.time_out_value = 60;
vm_srb->win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
+ SRB_FLAGS_DISABLE_SYNCH_TRANSFER;
/* Build the SRB */
switch (scmnd->sc_data_direction) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 80/86] bonding: fix panic on non-ARPHRD_ETHER enslave failure
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Jay Vosburgh
commit 40baec225765c54eefa870530dd613bad9829bb7 upstream.
Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
are not ARPHRD_ETHER, if needed, it resets the bonding device back to
ARPHRD_ETHER by calling ether_setup.
Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
if the bond device is up, leaving it in a quasi-down state without
having actually gone through dev_close. For bonding, if any periodic
work queue items are active (miimon, arp_interval, etc), those will
remain running, as they are stopped by bond_close. At this point, if
the bonding module is unloaded or the bond is deleted, the system will
panic when the work function is called.
This panic is resolved by calling dev_close on the bond itself
prior to calling ether_setup.
Cc: Nikolay Aleksandrov
Signed-off-by: Jay Vosburgh
Fixes: 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave
failure")
Acked-by: Nikolay Aleksandrov
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
drivers/net/bonding/bond_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 74dab00..da94d3c 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1662,6 +1662,7 @@ err_undo_flags:
slave_dev->dev_addr))
eth_hw_addr_random(bond_dev);
if (bond_dev->type != ARPHRD_ETHER) {
+ dev_close(bond_dev);
ether_setup(bond_dev);
bond_dev->flags |= IFF_MASTER;
bond_dev->priv_flags &= ~IFF_TX_SKB_SHARING;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang.
Hey, On 2 December 2015 at 22:26, Daniel Vetter wrote: > On Wed, Dec 02, 2015 at 11:35:16AM -0800, Eric Anholt wrote: >> Yes, I have thought about basing vc4-gpu-tools off of intel-gpu-tools. >> I've actually tried to build and use the kms testing stuff on vc4, and >> it was a total bust. Someone needs to do a lot of work to make igt >> useful for non-intel. If you'd like me to build my vc4 testing inside >> of igt, I'd someone to demo one of my tests building inside of igt, with >> the test runner working and none of the intel-specific tests reporting >> failure, and get me permission to just push code to that repository >> (It's hard enough getting piglit tests reviewed, vc4-specific tests and >> tools would never get review). > > Daniel Stone claimed that this Just Works but evidently it doesn't. > There's some autoconfig fail where igt wants too much intel crap that just > doesn't build on arm. Iirc Daniel had some patches floating around for > that. Yeah, it was working, though with my ARM farm still being in pieces, I haven't been able to keep on top of it lately. Apparently the patch to disable the ancilliary tools fixes the build, so I'll get that pushed when I can actually test it, or for the meantime: http://paste.fedoraproject.org/296836/09692714 This does still require libpciaccess and libdrm-intel to be built, but they _are_ totally possible to build on ARM, without any stupid hacks. My first cut at getting igt running on ARM (before Micah took over) actually started by eviscerating those as well, but it ended up being too much of a yak-shave. If you can get past those, you get a skip for all but the core tests. For the rest, they either need porting to just use dumb-buffers, or split such that the bits exercising Intel-specific tiling modes can be run separately, or left as Intel only. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 84/86] drm: Fix return value of drm_framebuffer_init()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Lukas Wunner
commit 3c67d839b30c7d6d6ab5c6fddac0f58ec8095d50 upstream.
In its original version, drm_framebuffer_init() returned a negative int
if drm_mode_object_get() failed (f453ba046074, "DRM: add mode setting
support").
This was accidentally disabled by commit 4b096ac10da0 ("drm: revamp
locking around fb creation/destruction"). Thus, drm_framebuffer_init()
pretends success if drm_mode_object_get() failed.
Reinstate the original behaviour. Also fix erroneous kernel-doc of
drm_mode_object_get().
Fixes: 4b096ac10da0 ("drm: revamp locking around fb creation/
destruction")
Cc: Daniel Vetter
Signed-off-by: Lukas Wunner
Signed-off-by: Daniel Vetter
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/drm_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 87591bb..a04e876 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -296,8 +296,7 @@ EXPORT_SYMBOL(drm_get_format_name);
* for tracking modes, CRTCs and connectors.
*
* RETURNS:
- * New unique (relative to other objects in @dev) integer identifier for the
- * object.
+ * Zero on success, error code on failure.
*/
static int drm_mode_object_get(struct drm_device *dev,
struct drm_mode_object *obj, uint32_t obj_type)
@@ -403,7 +402,7 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
out:
mutex_unlock(>mode_config.fb_lock);
- return 0;
+ return ret;
}
EXPORT_SYMBOL(drm_framebuffer_init);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 19/86] fs/proc, core/debug: Don't expose absolute kernel addresses via wchan
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Ingo Molnar
commit b2f73922d119686323f14fbbe46587f863852328 upstream.
So the /proc/PID/stat 'wchan' field (the 30th field, which contains
the absolute kernel address of the kernel function a task is blocked in)
leaks absolute kernel addresses to unprivileged user-space:
seq_put_decimal_ull(m, ' ', wchan);
The absolute address might also leak via /proc/PID/wchan as well, if
KALLSYMS is turned off or if the symbol lookup fails for some reason:
static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
unsigned long wchan;
char symname[KSYM_NAME_LEN];
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0) {
if (!ptrace_may_access(task, PTRACE_MODE_READ))
return 0;
seq_printf(m, "%lu", wchan);
} else {
seq_printf(m, "%s", symname);
}
return 0;
}
This isn't ideal, because for example it trivially leaks the KASLR offset
to any local attacker:
fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
8123b380
Most real-life uses of wchan are symbolic:
ps -eo pid:10,tid:10,wchan:30,comm
and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:
triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan
| tail -1
open("/proc/30833/wchan", O_RDONLY) = 6
There's one compatibility quirk here: procps relies on whether the
absolute value is non-zero - and we can provide that functionality
by outputing "0" or "1" depending on whether the task is blocked
(whether there's a wchan address).
These days there appears to be very little legitimate reason
user-space would be interested in the absolute address. The
absolute address is mostly historic: from the days when we
didn't have kallsyms and user-space procps had to do the
decoding itself via the System.map.
So this patch sets all numeric output to "0" or "1" and keeps only
symbolic output, in /proc/PID/wchan.
( The absolute sleep address can generally still be profiled via
perf, by tasks with sufficient privileges. )
Reviewed-by: Thomas Gleixner
Acked-by: Kees Cook
Acked-by: Linus Torvalds
Cc: Al Viro
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Denys Vlasenko
Cc: Dmitry Vyukov
Cc: Kostya Serebryany
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: kasan-dev
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20150930135917.ga3...@gmail.com
Signed-off-by: Ingo Molnar
[ kamal: backport to 3.13-stable: proc_pid_wchan context ]
Signed-off-by: Kamal Mostafa
---
Documentation/filesystems/proc.txt | 5 +++--
fs/proc/array.c| 16 ++--
fs/proc/base.c | 9 +++--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index d49f0be..dad2936 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -139,7 +139,8 @@ Table 1-1: Process specific entries in /proc
stat Process status
statm Process memory status information
statusProcess status in human readable form
- wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
+ symbol the task is blocked in - or "0" if not blocked.
pagemap Page table
stack Report full stack trace, enable via CONFIG_STACKTRACE
smaps a extension based on maps, showing the memory consumption of
@@ -301,7 +302,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
blocked bitmap of blocked signals
sigignbitmap of ignored signals
sigcatch bitmap of catched signals
- wchan address where process went to sleep
+ 0(place holder, used to be the wchan address, use
/proc/PID/wchan instead)
0 (place holder)
0 (place holder)
exit_signal signal to send to parent thread on exit
diff --git a/fs/proc/array.c b/fs/proc/array.c
index fafb03d..78f0f1d 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -380,7 +380,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task, int whole)
{
- unsigned long vsize, eip, esp, wchan = ~0UL;
+ unsigned long vsize, eip, esp, wchan = 0;
int priority, nice;
int tty_pgrp = -1, tty_nr = 0;
sigset_t sigign, sigcatch;
@@ -518,7 +518,19 @@ static int
[PATCH 3.13.y-ckt 83/86] ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Arnd Bergmann
commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream.
The z2 machine calls pxa27x_set_pwrmode() in order to power off
the machine, but this function gets discarded early at boot because
it is marked __init, as pointed out by kbuild:
WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the
function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
The function z2_power_off() references
the function __init pxa27x_set_pwrmode().
This is often because z2_power_off lacks a __init
annotation or the annotation of pxa27x_set_pwrmode is wrong.
This removes the __init section modifier to fix rebooting and the
build error.
Signed-off-by: Arnd Bergmann
Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend()
no longer available")
Signed-off-by: Robert Jarzmik
Signed-off-by: Kamal Mostafa
---
arch/arm/mach-pxa/include/mach/pxa27x.h | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/pxa27x.h
b/arch/arm/mach-pxa/include/mach/pxa27x.h
index 7cff640..66c4cbf 100644
--- a/arch/arm/mach-pxa/include/mach/pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/pxa27x.h
@@ -21,7 +21,7 @@
extern void __init pxa27x_map_io(void);
extern void __init pxa27x_init_irq(void);
-extern int __init pxa27x_set_pwrmode(unsigned int mode);
+extern int pxa27x_set_pwrmode(unsigned int mode);
extern void pxa27x_cpu_pm_enter(suspend_state_t state);
#define pxa27x_handle_irq ichp_handle_irq
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 301471a..4fc7c57 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -251,7 +251,7 @@ static struct clk_lookup pxa27x_clkregs[] = {
*/
static unsigned int pwrmode = PWRMODE_SLEEP;
-int __init pxa27x_set_pwrmode(unsigned int mode)
+int pxa27x_set_pwrmode(unsigned int mode)
{
switch (mode) {
case PWRMODE_SLEEP:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x900/0xe50
On Tue, 2015-12-01 at 21:20 +0100, Andrea Gelmini wrote: > Hi everybody, >and thanks a lot for your work. > >As soon as I plugged an external WD USB hard drive (details in the > attached file) >into USB3 port, I've got this (much more info in the attached files). >Using commit 2255702db4014d1c69d6037ed7bdad2d2e271985 > > Thanks again, > Andrea > > [ 542.582204] > == > [ 542.582220] BUG: KASAN: slab-out-of-bounds in > ses_enclosure_data_process+0x900/0xe50 [ses] at addr 88038c421c12 > [ 542.582223] Read of size 1 by task systemd-udevd/4017 > [ 542.582225] > = > [ 542.582227] BUG kmalloc-8 (Not tainted): kasan: bad access detected > [ 542.582228] > - > > [ 542.582229] Disabling lock debugging due to kernel taint > [ 542.582236] INFO: Allocated in ses_enclosure_data_process+0x1e6/0xe50 > [ses] age=1 cpu=2 pid=4017 > [ 542.582243] ___slab_alloc.constprop.27+0x379/0x3a0 > [ 542.582246] __slab_alloc.isra.24.constprop.26+0x26/0x40 > [ 542.582249] __kmalloc+0x19b/0x1e0 > [ 542.582253] ses_enclosure_data_process+0x1e6/0xe50 [ses] > [ 542.582256] ses_intf_add+0x9d6/0xe00 [ses] > [ 542.582261] class_interface_register+0x213/0x350 > [ 542.582264] scsi_register_interface+0x33/0x40 > [ 542.582268] ses_init+0x13/0x1000 [ses] > [ 542.582272] do_one_initcall+0x13c/0x2f0 > [ 542.582277] do_init_module+0x1d9/0x5bc > [ 542.582280] load_module+0x6029/0x9230 > [ 542.582283] SyS_finit_module+0x103/0x130 > [ 542.582288] entry_SYSCALL_64_fastpath+0x16/0x75 > [ 542.582293] INFO: Freed in sg_clean+0x12e/0x200 age=1 cpu=3 pid=4009 > [ 542.582296] __slab_free+0x292/0x3d0 > [ 542.582298] kfree+0x108/0x120 > [ 542.582300] sg_clean+0x12e/0x200 > [ 542.582302] usb_sg_wait+0x2ad/0x3d0 > [ 542.582307] usb_stor_bulk_transfer_sglist.part.3+0xc4/0x200 [usb_storage] > [ 542.582311] usb_stor_bulk_srb+0x184/0x280 [usb_storage] > [ 542.582315] usb_stor_Bulk_transport+0x53e/0xf80 [usb_storage] > [ 542.582319] usb_stor_invoke_transport+0xf2/0x1430 [usb_storage] > [ 542.582323] usb_stor_transparent_scsi_command+0x9/0x10 [usb_storage] > [ 542.582327] usb_stor_control_thread+0x530/0xac0 [usb_storage] > [ 542.582332] kthread+0x1c0/0x260 > [ 542.582335] ret_from_fork+0x3f/0x70 > [ 542.582339] INFO: Slab 0xea000e310800 objects=26 used=25 > fp=0x88038c421e78 flags=0x80004080 > [ 542.582341] INFO: Object 0x88038c421c08 @offset=7176 > fp=0x0008 > > [ 542.582345] Bytes b4 88038c421bf8: 01 00 00 00 01 00 00 00 74 97 fd ff > 00 00 00 00 t... > [ 542.582348] Object 88038c421c08: 08 00 00 00 00 00 00 00 > > [ 542.582354] CPU: 2 PID: 4017 Comm: systemd-udevd Tainted: GB > 4.4.0-rc3KASan-5-g2255702 #5 > [ 542.582356] Hardware name: LENOVO 2356LRG/2356LRG, BIOS G7ETA3WW (2.63 ) > 04/16/2015 > [ 542.582361] 88038c42 8800ac3ff6c0 819c3387 > 88038e404240 > [ 542.582365] 8800ac3ff6f0 813e22f4 88038e404240 > ea000e310800 > [ 542.582368] 88038c421c08 8800ac3ff718 > 813e69bf > [ 542.582369] Call Trace: > [ 542.582375] [] dump_stack+0x4b/0x74 > [ 542.582378] [] print_trailer+0xf4/0x150 > [ 542.582382] [] object_err+0x2f/0x40 > [ 542.582387] [] kasan_report_error+0x21c/0x540 > [ 542.582392] [] ? ses_recv_diag+0xac/0xe0 [ses] > [ 542.582397] [] __asan_report_load1_noabort+0x3e/0x40 > [ 542.582401] [] ? ses_enclosure_data_process+0x900/0xe50 > [ses] > [ 542.582406] [] ses_enclosure_data_process+0x900/0xe50 > [ses] > [ 542.582412] [] ? pm_runtime_init+0x364/0x410 > [ 542.582417] [] ses_intf_add+0x9d6/0xe00 [ses] > [ 542.582421] [] class_interface_register+0x213/0x350 > [ 542.582425] [] ? class_dev_iter_exit+0x10/0x10 > [ 542.582429] [] ? kvasprintf+0xf0/0xf0 > [ 542.582432] [] ? 0xc113 > [ 542.582435] [] scsi_register_interface+0x33/0x40 > [ 542.582439] [] ses_init+0x13/0x1000 [ses] > [ 542.582443] [] do_one_initcall+0x13c/0x2f0 > [ 542.582446] [] ? try_to_run_init_process+0x40/0x40 > [ 542.582450] [] ? kasan_unpoison_shadow+0x36/0x50 > [ 542.582454] [] ? kasan_unpoison_shadow+0x36/0x50 > [ 542.582458] [] ? __asan_register_globals+0x87/0xa0 > [ 542.582463] [] do_init_module+0x1d9/0x5bc > [ 542.582466] [] load_module+0x6029/0x9230 > [ 542.582469] [] ? symbol_put_addr+0x50/0x50 > [ 542.582475] [] ? module_frob_arch_sections+0x20/0x20 > [ 542.582479] [] ? open_exec+0x50/0x50 > [ 542.582486] [] ? ns_capable+0x4f/0xd0 > [ 542.582489] [] SyS_finit_module+0x103/0x130 > [ 542.582492] [] ? SyS_init_module+0x1d0/0x1d0 > [ 542.582497] [] entry_SYSCALL_64_fastpath+0x16/0x75 > [ 542.582498] Memory state around the
[PATCH 3.13.y-ckt 82/86] packet: fix match_fanout_group()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Eric Dumazet
commit 161642e24fee40fba2c5bc2ceacc00d118a22d65 upstream.
Recent TCP listener patches exposed a prior af_packet bug :
match_fanout_group() blindly assumes it is always safe
to cast sk to a packet socket to compare fanout with af_packet_priv
But SYNACK packets can be sent while attached to request_sock, which
are smaller than a "struct sock".
We can read non existent memory and crash.
Fixes: c0de08d04215 ("af_packet: don't emit packet on orig fanout group")
Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of
listener")
Signed-off-by: Eric Dumazet
Cc: Willem de Bruijn
Cc: Eric Leblond
Signed-off-by: David S. Miller
Signed-off-by: Kamal Mostafa
---
net/packet/af_packet.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 7f63613..b4cb15b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1288,10 +1288,10 @@ static void __fanout_unlink(struct sock *sk, struct
packet_sock *po)
static bool match_fanout_group(struct packet_type *ptype, struct sock * sk)
{
- if (ptype->af_packet_priv == (void*)((struct packet_sock *)sk)->fanout)
- return true;
+ if (sk->sk_family != PF_PACKET)
+ return false;
- return false;
+ return ptype->af_packet_priv == pkt_sk(sk)->fanout;
}
static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 77/86] MIPS: atomic: Fix comment describing atomic64_add_unless's return value.
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Ralf Baechle
commit f25319d2cb439249a6859f53ad42ffa332b0acba upstream.
Signed-off-by: Ralf Baechle
Fixes: f24219b4e90cf70ec4a211b17fbabc725a0ddf3c
(cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec)
Signed-off-by: Kamal Mostafa
---
arch/mips/include/asm/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
index 7eed2f2..4d1ae1a 100644
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -673,7 +673,7 @@ static __inline__ long atomic64_sub_if_positive(long i,
atomic64_t * v)
* @u: ...unless v is equal to u.
*
* Atomically adds @a to @v, so long as it was not @u.
- * Returns the old value of @v.
+ * Returns true iff @v was not @u.
*/
static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 86/86] TPM: Avoid reference to potentially freed memory
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Christophe JAILLET
commit eb8ed1eb9a158c460d10205eaff71fd4ac67c160 upstream.
Reference to the 'np' node is dropped before dereferencing the 'sizep' and
'basep' pointers, which could by then point to junk if the node has been
freed.
Refactor code to call 'of_node_put' later.
Fixes: c5df39262dd5 ("drivers/char/tpm: Add securityfs support for event log")
Signed-off-by: Christophe JAILLET
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Acked-by: Peter Huewe
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
drivers/char/tpm/tpm_of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 98ba2bd..565a0b3 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -53,17 +53,18 @@ int read_log(struct tpm_bios_log *log)
goto cleanup_eio;
}
- of_node_put(np);
log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
if (!log->bios_event_log) {
pr_err("%s: ERROR - Not enough memory for BIOS measurements\n",
__func__);
+ of_node_put(np);
return -ENOMEM;
}
log->bios_event_log_end = log->bios_event_log + *sizep;
memcpy(log->bios_event_log, __va(be64_to_cpup(basep)), *sizep);
+ of_node_put(np);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] mvneta Buffer Management and enhancements
Hi Marcin,
On mer., déc. 02 2015, Marcin Wojtas wrote:
>>>
2. Change condition in mvebu_mbus_get_dram_win_info to:
if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size -1))
>>>
>>> I think it would be the best solution.
>>
>> So I applied the following patch:
>> --- a/drivers/bus/mvebu-mbus.c
>> +++ b/drivers/bus/mvebu-mbus.c
>> @@ -964,7 +964,7 @@ int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8
>> *target, u8 *attr)
>> for (i = 0; i < dram->num_cs; i++) {
>> const struct mbus_dram_window *cs = dram->cs + i;
>>
>> - if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size))
>> {
>> + if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size -
>> 1)) {
>> *target = dram->mbus_dram_target_id;
>> *attr = cs->mbus_attr;
>> return 0;
>>
>> I didn't get any errors during boot related to the BM. However I did not
>> manage to use an ethernet interface. The udhcpc never managed to get an
>> IP and if I set the IP manually I could not ping.
>>
>> But on Armada 388 GP I didn't have any issue.
>>
>> Do you have some idea about waht I could check?
>>
>
> I replaced 2GB with 8GB DIMM and after that, on the same kernel/board,
> I can't ping either. Very strange, but as I can reproduce the issue,
> don't debug it, I will.
Thanks to care about it!
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 85/86] netfilter: nfnetlink: don't probe module if it exists
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Florian Westphal
commit dbc3617f4c1f9fcbe63612048cb9583fea1e11ab upstream.
nfnetlink_bind request_module()s all the time as nfnetlink_get_subsys()
shifts the argument by 8 to obtain the subsys id.
So using type instead of type << 8 always returns NULL.
Fixes: 03292745b02d11 ("netlink: add nlk->netlink_bind hook for module
auto-loading")
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Kamal Mostafa
---
net/netfilter/nfnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 8be4810..0910c4b 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -397,7 +397,7 @@ static void nfnetlink_bind(int group)
int type = nfnl_group2type[group];
rcu_read_lock();
- ss = nfnetlink_get_subsys(type);
+ ss = nfnetlink_get_subsys(type << 8);
if (!ss) {
rcu_read_unlock();
request_module("nfnetlink-subsys-%d", type);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 75/86] dmaengine: dw: convert to __ffs()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Andy Shevchenko
commit 39416677b95bf1ab8bbfa229ec7e511c96ad5d0c upstream.
We replace __fls() by __ffs() since we have to find a *minimum* data width that
satisfies both source and destination.
While here, rename dwc_fast_fls() to dwc_fast_ffs() which it really is.
Fixes: 4c2d56c574db (dw_dmac: introduce dwc_fast_fls())
Signed-off-by: Andy Shevchenko
Signed-off-by: Vinod Koul
Signed-off-by: Kamal Mostafa
---
drivers/dma/dw/core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index f882b56..b24ee31 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -176,7 +176,7 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
/*--*/
-static inline unsigned int dwc_fast_fls(unsigned long long v)
+static inline unsigned int dwc_fast_ffs(unsigned long long v)
{
/*
* We can be a lot more clever here, but this should take care
@@ -726,7 +726,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
dma_addr_t src,
dw->data_width[dwc->dst_master]);
src_width = dst_width = min_t(unsigned int, data_width,
- dwc_fast_fls(src | dest | len));
+ dwc_fast_ffs(src | dest | len));
ctllo = DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_DST_WIDTH(dst_width)
@@ -805,7 +805,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
switch (direction) {
case DMA_MEM_TO_DEV:
- reg_width = __fls(sconfig->dst_addr_width);
+ reg_width = __ffs(sconfig->dst_addr_width);
reg = sconfig->dst_addr;
ctllo = (DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_DST_WIDTH(reg_width)
@@ -825,7 +825,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
len = sg_dma_len(sg);
mem_width = min_t(unsigned int,
- data_width, dwc_fast_fls(mem | len));
+ data_width, dwc_fast_ffs(mem | len));
slave_sg_todev_fill_desc:
desc = dwc_desc_get(dwc);
@@ -865,7 +865,7 @@ slave_sg_todev_fill_desc:
}
break;
case DMA_DEV_TO_MEM:
- reg_width = __fls(sconfig->src_addr_width);
+ reg_width = __ffs(sconfig->src_addr_width);
reg = sconfig->src_addr;
ctllo = (DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_SRC_WIDTH(reg_width)
@@ -885,7 +885,7 @@ slave_sg_todev_fill_desc:
len = sg_dma_len(sg);
mem_width = min_t(unsigned int,
- data_width, dwc_fast_fls(mem | len));
+ data_width, dwc_fast_ffs(mem | len));
slave_sg_fromdev_fill_desc:
desc = dwc_desc_get(dwc);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 76/86] devres: fix a for loop bounds check
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Dan Carpenter
commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.
The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
DEVICE_COUNT_RESOURCE (16). This bug was found using a static checker.
It may be that the "if (!(mask & (1 << i)))" check means we never
actually go past the end of the array in real life.
Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
Signed-off-by: Dan Carpenter
Acked-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
lib/devres.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..20afaf1 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -423,7 +423,7 @@ void pcim_iounmap_regions(struct pci_dev *pdev, int mask)
if (!iomap)
return;
- for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ for (i = 0; i < PCIM_IOMAP_MAX; i++) {
if (!(mask & (1 << i)))
continue;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 74/86] mwifiex: fix mwifiex_rdeeprom_read()
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Dan Carpenter
commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream.
There were several bugs here.
1) The done label was in the wrong place so we didn't copy any
information out when there was no command given.
2) We were using PAGE_SIZE as the size of the buffer instead of
"PAGE_SIZE - pos".
3) snprintf() returns the number of characters that would have been
printed if there were enough space. If there was not enough space
(and we had fixed the memory corruption bug #2) then it would result
in an information leak when we do simple_read_from_buffer(). I've
changed it to use scnprintf() instead.
I also removed the initialization at the start of the function, because
I thought it made the code a little more clear.
Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex
driver')
Signed-off-by: Dan Carpenter
Acked-by: Amitkumar Karwar
Signed-off-by: Kalle Valo
Signed-off-by: Kamal Mostafa
---
drivers/net/wireless/mwifiex/debugfs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/debugfs.c
b/drivers/net/wireless/mwifiex/debugfs.c
index a5f9875..f84e5d7e 100644
--- a/drivers/net/wireless/mwifiex/debugfs.c
+++ b/drivers/net/wireless/mwifiex/debugfs.c
@@ -637,7 +637,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
(struct mwifiex_private *) file->private_data;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *) addr;
- int pos = 0, ret = 0, i;
+ int pos, ret, i;
u8 value[MAX_EEPROM_DATA];
if (!buf)
@@ -645,7 +645,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
if (saved_offset == -1) {
/* No command has been given */
- pos += snprintf(buf, PAGE_SIZE, "0");
+ pos = snprintf(buf, PAGE_SIZE, "0");
goto done;
}
@@ -654,17 +654,17 @@ mwifiex_rdeeprom_read(struct file *file, char __user
*ubuf,
(u16) saved_bytes, value);
if (ret) {
ret = -EINVAL;
- goto done;
+ goto out_free;
}
- pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
+ pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
for (i = 0; i < saved_bytes; i++)
- pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]);
-
- ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
+ pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]);
done:
+ ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
+out_free:
free_page(addr);
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 61/86] perf: Fix inherited events vs. tracepoint filters
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Peter Zijlstra
commit b71b437eedaed985062492565d9d421d975ae845 upstream.
Arnaldo reported that tracepoint filters seem to misbehave (ie. not
apply) on inherited events.
The fix is obvious; filters are only set on the actual (parent)
event, use the normal pattern of using this parent event for filters.
This is safe because each child event has a reference to it.
Reported-by: Arnaldo Carvalho de Melo
Tested-by: Arnaldo Carvalho de Melo
Signed-off-by: Peter Zijlstra (Intel)
Cc: Adrian Hunter
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Frédéric Weisbecker
Cc: Jiri Olsa
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/20151102095051.gn17...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
Signed-off-by: Kamal Mostafa
---
kernel/events/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f1aec1c..5a90a64 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5863,6 +5863,10 @@ static int perf_tp_filter_match(struct perf_event *event,
{
void *record = data->raw->data;
+ /* only top level events have filters set */
+ if (event->parent)
+ event = event->parent;
+
if (likely(!event->filter) || filter_match_preds(event->filter, record))
return 1;
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 54/86] ALSA: hda - Add Intel Lewisburg device IDs Audio
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Alexandra Yates
commit 5cf92c8b3dc5da59e05dc81bdc069cedf6f38313 upstream.
Adding Intel codename Lewisburg platform device IDs for audio.
[rearranged the position by tiwai]
Signed-off-by: Alexandra Yates
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal Mostafa
---
sound/pci/hda/hda_intel.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index a52278f..e4b081c 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -4074,6 +4074,11 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
{ PCI_DEVICE(0x8086, 0x8d21),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ /* Lewisburg */
+ { PCI_DEVICE(0x8086, 0xa1f0),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ { PCI_DEVICE(0x8086, 0xa270),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Lynx Point-LP */
{ PCI_DEVICE(0x8086, 0x9c20),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.13.y-ckt 04/86] drm/radeon: add quirk for ASUS R7 370
3.13.11-ckt31 -stable review patch. If anyone has any objections, please let
me know.
--
From: Alex Deucher
commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 upstream.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92260
Signed-off-by: Alex Deucher
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/radeon/si_dpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 82ff02a..5572e2d 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2917,6 +2917,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 },
+ { PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 12 },
{ 0, 0, 0, 0 },
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.13.y-ckt stable] Linux 3.13.11-ckt31 stable review
This is the start of the review cycle for the Linux 3.13.11-ckt31 stable kernel. This version contains 86 new patches, summarized below. The new patches are posted as replies to this message and also available in this git branch: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.13.y-review git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y-review The review period for version 3.13.11-ckt31 will be open for the next three days. To report a problem, please reply to the relevant follow-up patch message. For more information about the Linux 3.13.y-ckt extended stable kernel version, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable . -Kamal -- Documentation/filesystems/proc.txt | 5 +- MAINTAINERS| 1 + arch/arm/common/edma.c | 6 +- arch/arm/mach-pxa/include/mach/pxa27x.h| 2 +- arch/arm/mach-pxa/pxa27x.c | 2 +- arch/arm/mm/dma-mapping.c | 7 ++ arch/arm64/include/asm/ptrace.h| 16 ++--- arch/mips/include/asm/atomic.h | 2 +- arch/x86/include/uapi/asm/kvm.h| 3 + arch/x86/include/uapi/asm/svm.h| 1 + arch/x86/kernel/head_64.S | 8 +++ arch/x86/kernel/setup.c| 8 +++ arch/x86/kernel/verify_cpu.S | 12 ++-- arch/x86/kvm/svm.c | 22 +++--- arch/x86/kvm/vmx.c | 23 --- arch/xtensa/include/asm/asmmacro.h | 7 +- arch/xtensa/kernel/entry.S | 8 ++- arch/xtensa/kernel/head.S | 2 +- arch/xtensa/lib/usercopy.S | 6 +- arch/xtensa/platforms/iss/setup.c | 2 + arch/xtensa/platforms/xt2000/setup.c | 2 + arch/xtensa/platforms/xtfpga/setup.c | 2 + crypto/algif_hash.c| 12 +++- drivers/acpi/osl.c | 9 ++- drivers/bluetooth/ath3k.c | 4 ++ drivers/bluetooth/btusb.c | 2 + drivers/char/tpm/tpm_ibmvtpm.c | 2 +- drivers/char/tpm/tpm_of.c | 3 +- drivers/dma/dw/core.c | 12 ++-- drivers/firewire/ohci.c| 5 ++ drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/ast/ast_fb.c | 7 ++ drivers/gpu/drm/ast/ast_main.c | 1 + drivers/gpu/drm/ast/ast_mode.c | 2 + drivers/gpu/drm/drm_crtc.c | 5 +- drivers/gpu/drm/radeon/si_dpm.c| 2 + drivers/hid/hid-core.c | 2 +- drivers/iommu/intel-iommu.c| 42 ++-- drivers/md/dm-mpath.c | 7 +- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 +-- drivers/media/v4l2-core/videobuf2-dma-contig.c | 5 +- drivers/mtd/mtd_blkdevs.c | 10 +-- drivers/mtd/mtdpart.c | 4 +- drivers/net/bonding/bond_main.c| 1 + drivers/net/can/dev.c | 2 +- drivers/net/ethernet/marvell/mvneta.c | 2 +- .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +- drivers/net/macvtap.c | 2 +- drivers/net/usb/qmi_wwan.c | 5 +- drivers/net/wireless/mwifiex/debugfs.c | 14 ++-- drivers/power/wm831x_power.c | 6 +- drivers/scsi/megaraid/megaraid_sas.h | 2 + drivers/scsi/megaraid/megaraid_sas_base.c | 15 +++- drivers/scsi/scsi_sysfs.c | 2 +- drivers/scsi/storvsc_drv.c | 3 +- drivers/spi/spi-atmel.c| 3 +- drivers/spi/spi-ti-qspi.c | 3 +- drivers/staging/rtl8712/usb_intf.c | 1 + fs/binfmt_elf.c| 10 +-- fs/btrfs/file.c| 16 +++-- fs/btrfs/inode.c | 10 ++- fs/btrfs/xattr.c | 4 +- fs/cachefiles/rdwr.c | 79 +++--- fs/ext4/ext4_jbd2.c| 6 +- fs/ext4/resize.c | 4 +- fs/ext4/super.c| 12 +++- fs/fscache/netfs.c | 38 +-- fs/fscache/page.c | 2 +- fs/jbd2/journal.c | 6 +- fs/lockd/host.c| 7 +- fs/lockd/mon.c | 36
[3.13.y-ckt stable] Patch "fs/proc, core/debug: Don't expose absolute kernel addresses via wchan" has been added to staging queue
This is a note to let you know that I have just added a patch titled
fs/proc, core/debug: Don't expose absolute kernel addresses via wchan
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.13.y-queue
This patch is scheduled to be released in version 3.13.11-ckt31.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.13.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
--
>From fddf5ac90ea585bc9c6ac04eb4655a5bef6051ba Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Wed, 30 Sep 2015 15:59:17 +0200
Subject: fs/proc, core/debug: Don't expose absolute kernel addresses via wchan
commit b2f73922d119686323f14fbbe46587f863852328 upstream.
So the /proc/PID/stat 'wchan' field (the 30th field, which contains
the absolute kernel address of the kernel function a task is blocked in)
leaks absolute kernel addresses to unprivileged user-space:
seq_put_decimal_ull(m, ' ', wchan);
The absolute address might also leak via /proc/PID/wchan as well, if
KALLSYMS is turned off or if the symbol lookup fails for some reason:
static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
unsigned long wchan;
char symname[KSYM_NAME_LEN];
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0) {
if (!ptrace_may_access(task, PTRACE_MODE_READ))
return 0;
seq_printf(m, "%lu", wchan);
} else {
seq_printf(m, "%s", symname);
}
return 0;
}
This isn't ideal, because for example it trivially leaks the KASLR offset
to any local attacker:
fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
8123b380
Most real-life uses of wchan are symbolic:
ps -eo pid:10,tid:10,wchan:30,comm
and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:
triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan
| tail -1
open("/proc/30833/wchan", O_RDONLY) = 6
There's one compatibility quirk here: procps relies on whether the
absolute value is non-zero - and we can provide that functionality
by outputing "0" or "1" depending on whether the task is blocked
(whether there's a wchan address).
These days there appears to be very little legitimate reason
user-space would be interested in the absolute address. The
absolute address is mostly historic: from the days when we
didn't have kallsyms and user-space procps had to do the
decoding itself via the System.map.
So this patch sets all numeric output to "0" or "1" and keeps only
symbolic output, in /proc/PID/wchan.
( The absolute sleep address can generally still be profiled via
perf, by tasks with sufficient privileges. )
Reviewed-by: Thomas Gleixner
Acked-by: Kees Cook
Acked-by: Linus Torvalds
Cc: Al Viro
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Denys Vlasenko
Cc: Dmitry Vyukov
Cc: Kostya Serebryany
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: kasan-dev
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20150930135917.ga3...@gmail.com
Signed-off-by: Ingo Molnar
[ kamal: backport to 3.13-stable: proc_pid_wchan context ]
Signed-off-by: Kamal Mostafa
---
Documentation/filesystems/proc.txt | 5 +++--
fs/proc/array.c| 16 ++--
fs/proc/base.c | 9 +++--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index d49f0be..dad2936 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -139,7 +139,8 @@ Table 1-1: Process specific entries in /proc
stat Process status
statm Process memory status information
statusProcess status in human readable form
- wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
+ symbol the task is blocked in - or "0" if not blocked.
pagemap Page table
stack Report full stack trace, enable via CONFIG_STACKTRACE
smaps a extension based on maps, showing the memory consumption of
@@ -301,7 +302,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
blocked bitmap of blocked signals
sigignbitmap of ignored signals
sigcatch bitmap of catched signals
- wchan address where process went to sleep
+ 0(place holder, used to be the wchan address, use
/proc/PID/wchan instead)
0 (place holder)
0
RE: Skylake (XPS 13 9350) TSC is way off
+adrian > [0.00] tsc: PIT calibration matches HPET. 2 loops > [0.00] tsc: Detected 2399.975 MHz processor > [0.090897] TSC deadline timer enabled > [1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz > [1.960039] clocksource: tsc: mask: 0x max_cycles: > 0x22983e30402, max_idle_ns: 440795260848 ns > [2.959936] clocksource: Switched to clocksource tsc > [ 87.168211] Adjusting tsc more than 11% (5941981 vs 7759439) > > This is more or less Linus' latest tree (v4.4-rc3 plus some unrelated > platform driver patches). Hi Andy, Thanks for the note. I'll send you a debug version of turbostat, off list, since the list will just block mail with that attachment. thanks, -Len
Re: [PATCH 3/3] drivers: memory: prohibit offlining of memory blocks with missing sections
On Wed, 2 Dec 2015 09:07:01 -0600 Seth Jennings wrote: > bdee237c and 982792c7 introduced large block sizes for x86. > This made it possible to have multiple sections per memory > block where previously, there was a only every one section > per block. > > Since blocks consist of contiguous ranges of section, there > can be holes in the blocks where sections are not present. > If one attempts to offline such a block, a crash occurs since > the code is not designed to deal with this. > > This patch is a quick fix to gaurd against the crash by > not allowing blocks with non-present sections to be offlined. > > ... > > --- a/drivers/base/memory.c > +++ b/drivers/base/memory.c > @@ -303,6 +303,10 @@ static int memory_subsys_offline(struct device *dev) > if (mem->state == MEM_OFFLINE) > return 0; > > + /* Can't offline block with non-present sections */ > + if (mem->section_count != sections_per_block) > + return -EINVAL; > + > return memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE); > } [3/3] fixes a kernel crash so I've tagged it for -stable and shall move it ahead of [1/2] and [2/2], which are merely cleanups. This assumes that [3/3] is independent of the other two patches. I'll eat my hat if it isn't. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] perf/x86: add cycles:pp alias for Intel Atom
On Wed, Dec 2, 2015 at 11:37 AM, Liang, Kan wrote:
>
>
>> -Original Message-
>> From: Stephane Eranian [mailto:eran...@google.com]
>> Sent: Wednesday, December 02, 2015 1:28 PM
>> To: linux-kernel@vger.kernel.org
>> Cc: a...@redhat.com; pet...@infradead.org; mi...@elte.hu;
>> a...@linux.intel.com; Liang, Kan
>> Subject: [PATCH v1 2/2] perf/x86: add cycles:pp alias for Intel Atom
>>
>> This patch updates the PEBS support for Intel Atom to provide an alias for
>> the cycles:pp event used by perf record/top by default nowadays.
>>
>> On Atom only INST_RETIRED:ANY supports PEBS, so we use this event
>> instead with a large cmask to count cycles.
>>
>> Signed-off-by: Stephane Eranian
>> ---
>> arch/x86/kernel/cpu/perf_event_intel.c| 30
>> ++
>> arch/x86/kernel/cpu/perf_event_intel_ds.c | 2 ++
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
>> b/arch/x86/kernel/cpu/perf_event_intel.c
>> index 61f2577..7ff1e30 100644
>> --- a/arch/x86/kernel/cpu/perf_event_intel.c
>> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
>> @@ -2475,6 +2475,35 @@ static void intel_pebs_aliases_snb(struct
>> perf_event *event)
>> }
>> }
>>
>> +static void intel_pebs_aliases_atom(struct perf_event *event) {
>> + if ((event->hw.config & X86_RAW_EVENT_MASK) == 0x003c) {
>> + /*
>> + * Use an alternative encoding for
>> CPU_CLK_UNHALTED.THREAD_P
>> + * (0x003c) so that we can use it with PEBS.
>> + *
>> + * The regular CPU_CLK_UNHALTED.THREAD_P event
>> (0x003c) isn't
>> + * PEBS capable. However we can use UOPS_RETIRED.ALL
>> + * (0x01c2), which is a PEBS capable event, to get the same
>
> The comment isn't consistent with the code.
>
>> + * count.
>> + *
>> + * INST_RETIRED.ANY counts the number of cycles that
>> retires
>> + * CNTMASK instructions. By setting CNTMASK to a value
>> (16)
>> + * larger than the maximum number of instructions that
>> can be
>> + * retired per cycle (4) and then inverting the condition, we
>> + * count all cycles that retire 16 or less instructions, which
>> + * is every cycle.
>> + *
>> + * Thereby we gain a PEBS capable cycle counter.
>> + */
>> + u64 alt_config =
>> X86_CONFIG(.event=0xc0, .umask=0x00, .inv=1,
>> +.cmask=16);
>> +
>> + alt_config |= (event->hw.config &
>> ~X86_RAW_EVENT_MASK);
>> + event->hw.config = alt_config;
>> + }
>> +}
>> +
>> +
>> static unsigned long intel_pmu_free_running_flags(struct perf_event
>> *event) {
>> unsigned long flags = x86_pmu.free_running_flags; @@ -3332,6
>> +3361,7 @@ __init int intel_pmu_init(void)
>>
>> x86_pmu.event_constraints =
>> intel_gen_event_constraints;
>> x86_pmu.pebs_constraints =
>> intel_atom_pebs_event_constraints;
>> + x86_pmu.pebs_aliases = intel_pebs_aliases_atom;
>
> intel_pebs_aliases_atom looks the same as intel_pebs_aliases_core2.
> Why not reuse the existing intel_pebs_aliases_core2?
>
Sure, will do this in V2.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang.
On Wed, Dec 02, 2015 at 11:35:16AM -0800, Eric Anholt wrote: > Emil Velikov writes: > > > On 1 December 2015 at 20:35, Eric Anholt wrote: > >> This can be parsed with vc4-gpu-tools tools for trying to figure out > >> what was going on. > >> > > I might be pushing my luck here ... have you thought about basing > > (forking) vc4-gpu-tools of intel-gpu-tools ? I'd imagine that the > > macros and helpers will come in handy, despite that some are quite > > intel specific. > > > > On a related note - with the above project in place I'd imagine you > > have (re)considered about having libdrm-vc4 ? Copying hunks around > > might lead to interesting moments (as you have already noticed :-P) > > > > On that note I'll stop now with beating the libdrm drum :-) > > The headers and code that I copy between the two userspace locations > will go in libdrm when I have a kernel ABI, but vc4_drm.h can't go in > until merging to the kernel, and there's not a whole lot of point > without that. > > Yes, I have thought about basing vc4-gpu-tools off of intel-gpu-tools. > I've actually tried to build and use the kms testing stuff on vc4, and > it was a total bust. Someone needs to do a lot of work to make igt > useful for non-intel. If you'd like me to build my vc4 testing inside > of igt, I'd someone to demo one of my tests building inside of igt, with > the test runner working and none of the intel-specific tests reporting > failure, and get me permission to just push code to that repository > (It's hard enough getting piglit tests reviewed, vc4-specific tests and > tools would never get review). Daniel Stone claimed that this Just Works but evidently it doesn't. There's some autoconfig fail where igt wants too much intel crap that just doesn't build on arm. Iirc Daniel had some patches floating around for that. Wrt building tests itself I think we should require libdrm_$vendor everywhere, since without that you can embedded a vendor specific testcase into a shared one (e.g. to test tiled pageflipping). And if that's not possible then either we'll end up in #ifdef hell or code sharing is really hard, rendering a shared testsuite pretty useless. Wrt commit access I'm ok with that, atm rule for igt is to send to intel-gfx and push after 24h of no complaints. For purely vc4-specific stuff we should probably create a vc4 subdir. Wrt tests failing: I sometimes run the entire suite here on a radeon, and at least in the past that resulted in a perfect 100% skip score. So should work, too. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memcg, vmscan: Do not wait for writeback if killed
On Wed, 2 Dec 2015 15:26:18 +0100 Michal Hocko wrote:
> From: Michal Hocko
>
> Legacy memcg reclaim waits for pages under writeback to prevent from a
> premature oom killer invocation because there was no memcg dirty limit
> throttling implemented back then.
>
> This heuristic might complicate situation when the writeback cannot make
> forward progress because of the global OOM situation. E.g. filesystem
> backed by the loop device relies on the underlying filesystem hosting
> the image to make forward progress which cannot be guaranteed and so
> we might end up triggering OOM killer to resolve the situation. If the
> oom victim happens to be the task stuck in wait_on_page_writeback in the
> memcg reclaim then we are basically deadlocked.
>
> Introduce wait_on_page_writeback_killable and use it in this path to
> prevent from the issue. shrink_page_list will back off if the wait
> was interrupted.
>
> ...
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1021,10 +1021,19 @@ static unsigned long shrink_page_list(struct
> list_head *page_list,
>
> /* Case 3 above */
> } else {
> + int ret;
> +
> unlock_page(page);
> - wait_on_page_writeback(page);
> + ret = wait_on_page_writeback_killable(page);
> /* then go back and try same page again */
> list_add_tail(>lru, page_list);
> +
> + /*
> + * We've got killed while waiting here so
> + * expedite our way out from the reclaim
> + */
> + if (ret)
> + break;
> continue;
> }
> }
This function is 350 lines long and it takes a bit of effort to work
out what that `break' is breaking from and where it goes next. I think
you want a "goto keep_killed" here for consistency and sanity.
Also, there's high risk here of a pending signal causing the code to
fall into some busy loop where it repeatedly tries to do something but
then bales out without doing it. It's unobvious how this change avoids
such things. (Maybe it *does* avoid such things, but it should be
obvious!).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: ehci: ohci: use true/false for bool
2015-12-02 19:16 GMT-03:00 Greg Kroah-Hartman : > On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote: >> When declaring/initializing bool use true instead of 1. If it's false, >> there's no need to explicit initialize it, once it's default. >> >> Caught by coccinelle. >> >> Signed-off-by: Geyslan G. Bem >> --- >> drivers/usb/host/ehci-hcd.c | 2 +- >> drivers/usb/host/ohci-hcd.c | 4 ++-- >> drivers/usb/host/u132-hcd.c | 2 +- >> 3 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 48c92bf..1b01967 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO); >> MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets"); >> >> /* for flakey hardware, ignore overcurrent indicators */ >> -static bool ignore_oc = 0; >> +static bool ignore_oc; > > This should be a separate patch as it's doing something differently than > what you describe. > > thanks, > > greg k-h Greg, I think that the v2 description is ok, the title is misleading indeed. I'll make a new one entitled "fix bool initialization". Anything else? Thanks. -- Regards, Geyslan G. Bem hackingbits.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: brcmnand: Workaround false ECC uncorrectable errors
On Wed, Dec 02, 2015 at 10:08:20PM +0100, Jonas Gorski wrote: > On Wed, Dec 2, 2015 at 9:54 PM, Brian Norris > wrote: > > If that's really an issue (i.e., we have an implementation + data), I'm > > sure we could add optimization to nand_check_erased_ecc_chunk() to > > support the bitflip_threshold == 0 case. > > Maybe I'm missing something, but wasn't the point of introducing > nand_check_erased_ecc_chunk that bitflips in erased pages should be > treated as bitflips corrected by the ecc, and therefore fixed up > before passing the data further on? So having a theshold of 0 would be > wrong / no protection at all, and could be quite destructive on MLC > nand, where bitflips in erased pages are rather common. Yes, that would be pretty destructive on MLC NAND. But there might be cases where this is reasonable. For instance, we might have: (a) SLC NAND that specifies up to 1 bitflip per 512 bytes (b) a Hamming ECC engine that can correct 1 bitflip (c) said Hamming engine does not handle all-0xff pages correctly, nor does it handle near-0xff pages (e.g., with a single 0 bit) correctly Now, we might (for instance) allow up to ecc_strength / 2 bitflips in erased pages [1], as a general rule, but for the above case, that means we don't allow any on Hamming ECC. Hence, bitflip_threshold = 1 / 2 = 0. This is kind of a degenerate case, so we might consider supporting it differently than we would for BCH. e.g., don't use nand_check_erased_ecc_chunk() at all. Brian [1] We might do this because we can expect that if an unprogrammed page has N bitflips, there might be even more than N bitflips after programming the page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
