[ 19/75] tty/8250_pnp: serial port detection regression since v3.7
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Sean Young s...@mess.org
commit 77e372a3d82e5e4878ce1962207edd766773cc76 upstream.
The InsydeH2O BIOS (version dated 09/12/2011) has the following in
its pnp resouces for its serial ports:
$ cat /sys/bus/pnp/devices/00:0b/resources
state = active
io disabled
irq disabled
We do not check if the resources are disabled, and create a bogus
ttyS* device. Since commit 835d844d1a28e (8250_pnp: do pnp probe
before legacy probe) we get a bogus ttyS0, which prevents the legacy
probe from detecting it.
Note, the BIOS can also be upgraded, fixing this problem, but for people
who can't do that, this fix is needed.
Reported-by: Vincent Deffontaines vinc...@gryzor.com
Tested-by: Vincent Deffontaines vinc...@gryzor.com
Signed-off-by: Sean Young s...@mess.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/tty/serial/8250/8250_pnp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -429,6 +429,7 @@ serial_pnp_probe(struct pnp_dev *dev, co
{
struct uart_8250_port uart;
int ret, line, flags = dev_id-driver_data;
+ struct resource *res = NULL;
if (flags UNKNOWN_DEV) {
ret = serial_pnp_guess_board(dev);
@@ -439,11 +440,12 @@ serial_pnp_probe(struct pnp_dev *dev, co
memset(uart, 0, sizeof(uart));
if (pnp_irq_valid(dev, 0))
uart.port.irq = pnp_irq(dev, 0);
- if ((flags CIR_PORT) pnp_port_valid(dev, 2)) {
- uart.port.iobase = pnp_port_start(dev, 2);
- uart.port.iotype = UPIO_PORT;
- } else if (pnp_port_valid(dev, 0)) {
- uart.port.iobase = pnp_port_start(dev, 0);
+ if ((flags CIR_PORT) pnp_port_valid(dev, 2))
+ res = pnp_get_resource(dev, IORESOURCE_IO, 2);
+ else if (pnp_port_valid(dev, 0))
+ res = pnp_get_resource(dev, IORESOURCE_IO, 0);
+ if (pnp_resource_enabled(res)) {
+ uart.port.iobase = res-start;
uart.port.iotype = UPIO_PORT;
} else if (pnp_mem_valid(dev, 0)) {
uart.port.mapbase = pnp_mem_start(dev, 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/
[ 18/75] ext3: Fix format string issues
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Lars-Peter Clausen l...@metafoo.de
commit 8d0c2d10dd72c5292eda7a06231056a4c972e4cc upstream.
ext3_msg() takes the printk prefix as the second parameter and the
format string as the third parameter. Two callers of ext3_msg omit the
prefix and pass the format string as the second parameter and the first
parameter to the format string as the third parameter. In both cases
this string comes from an arbitrary source. Which means the string may
contain format string characters, which will
lead to undefined and potentially harmful behavior.
The issue was introduced in commit 4cf46b67eb(ext3: Unify log messages
in ext3) and is fixed by this patch.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
fs/ext3/super.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -353,7 +353,7 @@ static struct block_device *ext3_blkdev_
return bdev;
fail:
- ext3_msg(sb, error: failed to open journal device %s: %ld,
+ ext3_msg(sb, KERN_ERR, error: failed to open journal device %s: %ld,
__bdevname(dev, b), PTR_ERR(bdev));
return NULL;
@@ -887,7 +887,7 @@ static ext3_fsblk_t get_sb_block(void **
/*todo: use simple_strtoll with 32bit ext3 */
sb_block = simple_strtoul(options, options, 0);
if (*options *options != ',') {
- ext3_msg(sb, error: invalid sb specification: %s,
+ ext3_msg(sb, KERN_ERR, error: invalid sb specification: %s,
(char *) *data);
return 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/
[ 16/75] qcserial: bind to DM/DIAG port on Gobi 1K devices
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams d...@redhat.com
commit 3f8bc5e4da29c7e05edeca6b475abb4fb01a5a13 upstream.
Turns out we just need altsetting 1 and then we can talk to it.
Signed-off-by: Dan Williams d...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/qcserial.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -197,12 +197,15 @@ static int qcprobe(struct usb_serial *se
if (is_gobi1k) {
/* Gobi 1K USB layout:
-* 0: serial port (doesn't respond)
+* 0: DM/DIAG (use libqcdm from ModemManager for communication)
* 1: serial port (doesn't respond)
* 2: AT-capable modem port
* 3: QMI/net
*/
- if (ifnum == 2)
+ if (ifnum == 0) {
+ dev_dbg(dev, Gobi 1K DM/DIAG interface found\n);
+ altsetting = 1;
+ } else if (ifnum == 2)
dev_dbg(dev, Modem port found\n);
else
altsetting = -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/
[ 15/75] staging: comedi: dt9812: use CR_CHAN() for channel number
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Ian Abbott abbo...@mev.co.uk
commit 564c526a1bed5e42b5cd52cfe1752c4296ef17a6 upstream.
As pointed out by Dan Carpenper in
http://driverdev.linuxdriverproject.org/pipermail/devel/2013-February/036025.html,
the dt9812 comedi driver's use of the `chanspec` member of `struct
comedi_insn` as a channel number is incorrect. Change it to use
`CR_CHAN(insn-chanspec)` as the channel number (where `insn` is a
pointer to the `struct comedi_insn` being processed).
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Cc: Anders Blomdell anders.blomd...@control.lth.se
Signed-off-by: Ian Abbott abbo...@mev.co.uk
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/staging/comedi/drivers/dt9812.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/drivers/staging/comedi/drivers/dt9812.c
+++ b/drivers/staging/comedi/drivers/dt9812.c
@@ -948,12 +948,13 @@ static int dt9812_di_rinsn(struct comedi
unsigned int *data)
{
struct comedi_dt9812 *devpriv = dev-private;
+ unsigned int channel = CR_CHAN(insn-chanspec);
int n;
u8 bits = 0;
dt9812_digital_in(devpriv-slot, bits);
for (n = 0; n insn-n; n++)
- data[n] = ((1 insn-chanspec) bits) != 0;
+ data[n] = ((1 channel) bits) != 0;
return n;
}
@@ -962,12 +963,13 @@ static int dt9812_do_winsn(struct comedi
unsigned int *data)
{
struct comedi_dt9812 *devpriv = dev-private;
+ unsigned int channel = CR_CHAN(insn-chanspec);
int n;
u8 bits = 0;
dt9812_digital_out_shadow(devpriv-slot, bits);
for (n = 0; n insn-n; n++) {
- u8 mask = 1 insn-chanspec;
+ u8 mask = 1 channel;
bits = ~mask;
if (data[n])
@@ -982,13 +984,13 @@ static int dt9812_ai_rinsn(struct comedi
unsigned int *data)
{
struct comedi_dt9812 *devpriv = dev-private;
+ unsigned int channel = CR_CHAN(insn-chanspec);
int n;
for (n = 0; n insn-n; n++) {
u16 value = 0;
- dt9812_analog_in(devpriv-slot, insn-chanspec, value,
-DT9812_GAIN_1);
+ dt9812_analog_in(devpriv-slot, channel, value, DT9812_GAIN_1);
data[n] = value;
}
return n;
@@ -999,12 +1001,13 @@ static int dt9812_ao_rinsn(struct comedi
unsigned int *data)
{
struct comedi_dt9812 *devpriv = dev-private;
+ unsigned int channel = CR_CHAN(insn-chanspec);
int n;
u16 value;
for (n = 0; n insn-n; n++) {
value = 0;
- dt9812_analog_out_shadow(devpriv-slot, insn-chanspec, value);
+ dt9812_analog_out_shadow(devpriv-slot, channel, value);
data[n] = value;
}
return n;
@@ -1015,10 +1018,11 @@ static int dt9812_ao_winsn(struct comedi
unsigned int *data)
{
struct comedi_dt9812 *devpriv = dev-private;
+ unsigned int channel = CR_CHAN(insn-chanspec);
int n;
for (n = 0; n insn-n; n++)
- dt9812_analog_out(devpriv-slot, insn-chanspec, data[n]);
+ dt9812_analog_out(devpriv-slot, channel, data[n]);
return n;
}
--
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/
[ 03/75] virtio: rng: disallow multiple device registrations, fixes crashes
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Amit Shah amit.s...@redhat.com
commit e84e7a56a3aa2963db506299e29a5f3f09377f9b upstream.
The code currently only supports one virtio-rng device at a time.
Invoking guests with multiple devices causes the guest to blow up.
Check if we've already registered and initialised the driver. Also
cleanup in case of registration errors or hot-unplug so that a new
device can be used.
Reported-by: Peter Krempa pkre...@redhat.com
Reported-by: yunzh...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/char/hw_random/virtio-rng.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -92,14 +92,22 @@ static int probe_common(struct virtio_de
{
int err;
+ if (vq) {
+ /* We only support one device for now */
+ return -EBUSY;
+ }
/* We expect a single virtqueue. */
vq = virtio_find_single_vq(vdev, random_recv_done, input);
- if (IS_ERR(vq))
- return PTR_ERR(vq);
+ if (IS_ERR(vq)) {
+ err = PTR_ERR(vq);
+ vq = NULL;
+ return err;
+ }
err = hwrng_register(virtio_hwrng);
if (err) {
vdev-config-del_vqs(vdev);
+ vq = NULL;
return err;
}
@@ -112,6 +120,7 @@ static void remove_common(struct virtio_
busy = false;
hwrng_unregister(virtio_hwrng);
vdev-config-del_vqs(vdev);
+ vq = NULL;
}
static int virtrng_probe(struct virtio_device *vdev)
--
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/
[ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Stern st...@rowland.harvard.edu
commit 6402c796d3b4205d3d7296157956c5100a05d7d6 upstream.
This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers. After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see
http://marc.info/?l=linux-usbm=135492071812265w=2
http://marc.info/?l=linux-usbm=136182570800963w=2
This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH. The extra IAA delay gives the
controller time to perform its final writeback.
Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently. More through luck than anything
else, it hasn't caused any apparent problems. However, it does
interact badly with the path that follows this one, so it needs to be
addressed.
This is the first part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Stephen Thirlwall s...@dr.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/host/ehci-hcd.c |6 ++
drivers/usb/host/ehci-q.c | 18 ++
2 files changed, 16 insertions(+), 8 deletions(-)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -748,11 +748,9 @@ static irqreturn_t ehci_irq (struct usb_
/* guard against (alleged) silicon errata */
if (cmd CMD_IAAD)
ehci_dbg(ehci, IAA with IAAD still set?\n);
- if (ehci-async_iaa) {
+ if (ehci-async_iaa)
COUNT(ehci-stats.iaa);
- end_unlink_async(ehci);
- } else
- ehci_dbg(ehci, IAA with nothing unlinked?\n);
+ end_unlink_async(ehci);
}
/* remote wakeup [4.3.1] */
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1170,7 +1170,7 @@ static void single_unlink_async(struct e
struct ehci_qh *prev;
/* Add to the end of the list of QHs waiting for the next IAAD */
- qh-qh_state = QH_STATE_UNLINK;
+ qh-qh_state = QH_STATE_UNLINK_WAIT;
if (ehci-async_unlink)
ehci-async_unlink_last-unlink_next = qh;
else
@@ -1213,9 +1213,19 @@ static void start_iaa_cycle(struct ehci_
/* Do only the first waiting QH (nVidia bug?) */
qh = ehci-async_unlink;
- ehci-async_iaa = qh;
- ehci-async_unlink = qh-unlink_next;
- qh-unlink_next = NULL;
+
+ /*
+* Intel (?) bug: The HC can write back the overlay region
+* even after the IAA interrupt occurs. In self-defense,
+* always go through two IAA cycles for each QH.
+*/
+ if (qh-qh_state == QH_STATE_UNLINK_WAIT) {
+ qh-qh_state = QH_STATE_UNLINK;
+ } else {
+ ehci-async_iaa = qh;
+ ehci-async_unlink = qh-unlink_next;
+ qh-unlink_next = NULL;
+ }
/* Make sure the unlinks are all visible to the hardware */
wmb();
--
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/
[ 01/75] qcaux: add Franklin U600
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams d...@redhat.com
commit 2d90e63603ac235aecd7d20e234616e0682c8b1f upstream.
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: Dan Williams d...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/qcaux.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/usb/serial/qcaux.c
@@ -69,6 +69,7 @@ static struct usb_device_id id_table[] =
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff)
}, /* NMEA */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff)
}, /* WMC */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff)
}, /* DIAG */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1fac, 0x0151, 0xff, 0xff, 0xff) },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
--
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/
[ 05/75] USB: cdc-wdm: fix buffer overflow
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Oliver Neukum oneu...@suse.de
commit c0f5ecee4e741667b2493c742b60b6218d40b3aa upstream.
The buffer for responses must not overflow.
If this would happen, set a flag, drop the data and return
an error after user space has read all remaining data.
Signed-off-by: Oliver Neukum oli...@neukum.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/class/cdc-wdm.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -56,6 +56,7 @@ MODULE_DEVICE_TABLE (usb, wdm_ids);
#define WDM_RESPONDING 7
#define WDM_SUSPENDING 8
#define WDM_RESETTING 9
+#define WDM_OVERFLOW 10
#define WDM_MAX16
@@ -155,6 +156,7 @@ static void wdm_in_callback(struct urb *
{
struct wdm_device *desc = urb-context;
int status = urb-status;
+ int length = urb-actual_length;
spin_lock(desc-iuspin);
clear_bit(WDM_RESPONDING, desc-flags);
@@ -185,9 +187,17 @@ static void wdm_in_callback(struct urb *
}
desc-rerr = status;
- desc-reslength = urb-actual_length;
- memmove(desc-ubuf + desc-length, desc-inbuf, desc-reslength);
- desc-length += desc-reslength;
+ if (length + desc-length desc-wMaxCommand) {
+ /* The buffer would overflow */
+ set_bit(WDM_OVERFLOW, desc-flags);
+ } else {
+ /* we may already be in overflow */
+ if (!test_bit(WDM_OVERFLOW, desc-flags)) {
+ memmove(desc-ubuf + desc-length, desc-inbuf, length);
+ desc-length += length;
+ desc-reslength = length;
+ }
+ }
skip_error:
wake_up(desc-wait);
@@ -435,6 +445,11 @@ retry:
rv = -ENODEV;
goto err;
}
+ if (test_bit(WDM_OVERFLOW, desc-flags)) {
+ clear_bit(WDM_OVERFLOW, desc-flags);
+ rv = -ENOBUFS;
+ goto err;
+ }
i++;
if (file-f_flags O_NONBLOCK) {
if (!test_bit(WDM_READ, desc-flags)) {
@@ -478,6 +493,7 @@ retry:
spin_unlock_irq(desc-iuspin);
goto retry;
}
+
if (!desc-reslength) { /* zero length read */
dev_dbg(desc-intf-dev, %s: zero length - clearing
WDM_READ\n, __func__);
clear_bit(WDM_READ, desc-flags);
@@ -1004,6 +1020,7 @@ static int wdm_post_reset(struct usb_int
struct wdm_device *desc = wdm_find_device(intf);
int rv;
+ clear_bit(WDM_OVERFLOW, desc-flags);
clear_bit(WDM_RESETTING, desc-flags);
rv = recover_from_urb_loss(desc);
mutex_unlock(desc-wlock);
--
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/
[ 07/75] usb: dwc3: core: dont forget to free coherent memory
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Felipe Balbi ba...@ti.com commit d9b4330adec006c2e8907bdcacd9dcc0e8874d18 upstream. commit 3921426 (usb: dwc3: core: move event buffer allocation out of dwc3_core_init()) introduced a memory leak of the coherent memory we use as event buffers on dwc3 driver. If the driver is compiled as a dynamically loadable module and use constantly loads and unloads the driver, we will continue to leak the coherent memory allocated during -probe() because dwc3_free_event_buffers() is never called during -remove(). Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/usb/dwc3/core.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -575,6 +575,7 @@ static int dwc3_remove(struct platform_d break; } + dwc3_free_event_buffers(dwc); dwc3_core_exit(dwc); return 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/
[ 11/75] USB: storage: fix Huawei mode switching regression
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork bj...@mork.no
commit ab4b71644a26d1ab92b987b2fd30e17c25e89f85 upstream.
This reverts commit 200e0d99 (USB: storage: optimize to match the
Huawei USB storage devices and support new switch command and the
followup bugfix commit cd060956 (USB: storage: properly handle
the endian issues of idProduct).
The commit effectively added a large number of Huawei devices to
the deprecated usb-storage mode switching logic. Many of these
devices have been in use and supported by the userspace
usb_modeswitch utility for years. Forcing the switching inside
the kernel causes a number of regressions as a result of ignoring
existing onfigurations, and also completely takes away the ability
to configure mode switching per device/system/user.
Known regressions caused by this:
- Some of the devices support multiple modes, using different
switching commands. There are existing configurations taking
advantage of this.
- There is a real use case for disabling mode switching and
instead mounting the exposed storage device. This becomes
impossible with switching logic inside the usb-storage driver.
- At least on device fail as a result of the usb-storage switching
command, becoming completely unswitchable. This is possibly a
firmware bug, but still a regression because the device work as
expected using usb_modeswitch defaults.
In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
breaking already working systems. The long term plan is to remove
the list, not to add to it. Ref:
http://permalink.gmane.org/gmane.linux.usb.general/28543
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: fangxiao...@huawei.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/storage/initializers.c | 76
drivers/usb/storage/initializers.h |4
drivers/usb/storage/unusual_devs.h | 329 -
3 files changed, 331 insertions(+), 78 deletions(-)
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI usb dongles in multi-port mode */
-static int usb_stor_huawei_feature_init(struct us_data *us)
+/* This places the HUAWEI E220 devices in multi-port mode */
+int usb_stor_huawei_e220_init(struct us_data *us)
{
int result;
@@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
-
-/*
- * It will send a scsi switch command called rewind' to huawei dongle.
- * When the dongle receives this command at the first time,
- * it will reboot immediately. After rebooted, it will ignore this command.
- * So it is unnecessary to read its response.
- */
-static int usb_stor_huawei_scsi_init(struct us_data *us)
-{
- int result = 0;
- int act_len = 0;
- struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us-iobuf;
- char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
- bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
- bcbw-Tag = 0;
- bcbw-DataTransferLength = 0;
- bcbw-Flags = bcbw-Lun = 0;
- bcbw-Length = sizeof(rewind_cmd);
- memset(bcbw-CDB, 0, sizeof(bcbw-CDB));
- memcpy(bcbw-CDB, rewind_cmd, sizeof(rewind_cmd));
-
- result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe, bcbw,
- US_BULK_CB_WRAP_LEN, act_len);
- US_DEBUGP(transfer actual length=%d, result=%d\n, act_len, result);
- return result;
-}
-
-/*
- * It tries to find the supported Huawei USB dongles.
- * In Huawei, they assign the following product IDs
- * for all of their mobile broadband dongles,
- * including the new dongles in the future.
- * So if the product ID is not included in this list,
- * it means it is not Huawei's mobile broadband dongles.
- */
-static int usb_stor_huawei_dongles_pid(struct us_data *us)
-{
- struct usb_interface_descriptor *idesc;
- int idProduct;
-
- idesc = us-pusb_intf-cur_altsetting-desc;
- idProduct = le16_to_cpu(us-pusb_dev-descriptor.idProduct);
- /* The first port is CDROM,
-* means the dongle in the single port mode,
-* and a switch command is required to be sent. */
- if (idesc idesc-bInterfaceNumber == 0) {
- if ((idProduct == 0x1001)
- || (idProduct == 0x1003)
- || (idProduct == 0x1004)
- || (idProduct = 0x1401 idProduct = 0x1500)
- || (idProduct = 0x1505 idProduct = 0x1600)
- || (idProduct = 0x1c02 idProduct =
[ 10/75] usb: serial: Add Rigblaster Advantage to device table
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Steve Conklin sconk...@canonical.com
commit a57e82a18779ab8a5e5a1f5841cef937cf578913 upstream.
The Rigblaster Advantage is an amateur radio interface sold by West Mountain
Radio. It contains a cp210x serial interface but the device ID is not in
the driver.
Signed-off-by: Steve Conklin sconk...@canonical.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -85,6 +85,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x813F) }, /* Tams Master Easy Control */
{ USB_DEVICE(0x10C4, 0x814A) }, /* West Mountain Radio RIGblaster PP */
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
+ { USB_DEVICE(0x2405, 0x0003) }, /* West Mountain Radio RIGblaster
Advantage */
{ USB_DEVICE(0x10C4, 0x8156) }, /* BG H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
{ USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
--
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/
[ 09/75] USB: added support for Cinterions products AH6 and PLS8
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Schmiedl christian.schmi...@gemalto.com
commit 1941138e1c024ecb5bd797d414928d3eb94d8662 upstream.
add support for Cinterion's products AH6 and PLS8 by adding Product IDs
and USB_DEVICE tuples.
Signed-off-by: Christian Schmiedl christian.schmi...@gemalto.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/option.c |4
1 file changed, 4 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -341,6 +341,8 @@ static void option_instat_callback(struc
#define CINTERION_PRODUCT_EU3_E0x0051
#define CINTERION_PRODUCT_EU3_P0x0052
#define CINTERION_PRODUCT_PH8 0x0053
+#define CINTERION_PRODUCT_AH6 0x0055
+#define CINTERION_PRODUCT_PLS8 0x0060
/* Olivetti products */
#define OLIVETTI_VENDOR_ID 0x0b3c
@@ -1261,6 +1263,8 @@ static const struct usb_device_id option
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_E) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_P) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8) },
+ { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AH6) },
+ { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLS8) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDMNET) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDM) },
--
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/
[ 08/75] usb: cp210x new Vendor/Device IDs
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Matwey V. Kornilov mat...@sai.msu.ru
commit be3101c23394af59694c8a2aae6d07f5da62fea5 upstream.
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz
and licensed under the terms of GPLv2.
Moreover, I've tested this changes with Lake Shore 335 in my labs.
Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/cp210x.c | 19 +++
1 file changed, 19 insertions(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -150,6 +150,25 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
+ { USB_DEVICE(0x1FB9, 0x0100) }, /* Lake Shore Model 121 Current Source
*/
+ { USB_DEVICE(0x1FB9, 0x0200) }, /* Lake Shore Model 218A Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0201) }, /* Lake Shore Model 219 Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0202) }, /* Lake Shore Model 233 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0203) }, /* Lake Shore Model 235 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0300) }, /* Lake Shore Model 335 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0301) }, /* Lake Shore Model 336 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0302) }, /* Lake Shore Model 350 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0303) }, /* Lake Shore Model 371 AC Bridge */
+ { USB_DEVICE(0x1FB9, 0x0400) }, /* Lake Shore Model 411 Handheld
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0401) }, /* Lake Shore Model 425 Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0402) }, /* Lake Shore Model 455A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0403) }, /* Lake Shore Model 475A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0404) }, /* Lake Shore Model 465 Three Axis
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0600) }, /* Lake Shore Model 625A
Superconducting MPS */
+ { USB_DEVICE(0x1FB9, 0x0601) }, /* Lake Shore Model 642A Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller
*/
+ { USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
--
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: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Daniel Vetter wrote: Yep, there's a big comment in the irq handler for that chipset that we have a gaping race with when using MSI interrupts. Although the comment bodly claims that the race is small enough to avoid the dreaded nobody cared message. Looks like gmbus is good at hitting that race - on newer chips it already brought up a similar race in handling pch interrupts. I see ... will target my focus in that direction, thanks. Can you please give the below patch a whirl? It removes the probably race msi race avoidance code and replaces it with the same trick Paulo used to fix pch irq handling races. Unfortunately it didn't change anything, the spurious interrupt report is still there. -- Jiri Kosina SUSE Labs -- 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/
[ 04/75] USB: option: add Huawei E5331
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork bj...@mork.no
commit daec90e7382cbd0e73eb6861109b3da91e5ab1f3 upstream.
Another device using CDC ACM with vendor specific protocol to mark
serial functions.
Signed-off-by: Bjørn Mork bj...@mork.no
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/option.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -579,6 +579,7 @@ static const struct usb_device_id option
{ USB_DEVICE(QUANTA_VENDOR_ID, 0xea42),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c05,
USB_CLASS_COMM, 0x02, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c1f,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23,
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
--
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: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Yinghai Lu wrote: Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost interrupts go away. My understanding from the other mail is that DAniel Vetter already has an idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully this datapoint regarding MSI will fit into it. What is /proc/interrupts difference between with and without pci=nomsi ? drm is forced to share irq 16? Yup, IRQ 16 is being shared, and one of the owners is i915. -- Jiri Kosina SUSE Labs -- 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/
[ 02/75] xen/pciback: Dont disable a PCI device that is already disabled.
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Konrad Rzeszutek Wilk konrad.w...@oracle.com commit bdc5c1812cea6efe1aaefb3131fcba28cd0b2b68 upstream. While shuting down a HVM guest with pci devices passed through we get this: pciback :04:00.0: restoring config space at offset 0x4 (was 0x10, writing 0x12) [ cut here ] WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0() Hardware name: MS-7640 Device pciback disabling already-disabled device Modules linked in: Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1 Call Trace: [8106994a] warn_slowpath_common+0x7a/0xc0 [81069a31] warn_slowpath_fmt+0x41/0x50 [813cf288] pci_disable_device+0x88/0xa0 [814554a7] xen_pcibk_reset_device+0x37/0xd0 [81454b6f] ? pcistub_put_pci_dev+0x6f/0x120 [81454b8d] pcistub_put_pci_dev+0x8d/0x120 [814582a9] __xen_pcibk_release_devices+0x59/0xa0 This fixes the bug. Reported-and-Tested-by: Sander Eikelenboom li...@eikelenboom.it Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/xen/xen-pciback/pciback_ops.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/xen/xen-pciback/pciback_ops.c +++ b/drivers/xen/xen-pciback/pciback_ops.c @@ -113,7 +113,8 @@ void xen_pcibk_reset_device(struct pci_d if (dev-msi_enabled) pci_disable_msi(dev); #endif - pci_disable_device(dev); + if (pci_is_enabled(dev)) + pci_disable_device(dev); pci_write_config_word(dev, PCI_COMMAND, 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 0/4] Misc MRF24J40 Fixes
These are fairly straight-forward. Alan Ott (4): mrf24j40: pinctrl support mrf24j40: Warn if transmit interrupts timeout mrf24j40: Increase max SPI speed to 10MHz mrf24j40: Fix byte-order of IEEE address drivers/net/ieee802154/mrf24j40.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 1.7.11.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 1/4] mrf24j40: pinctrl support
Activate pinctrl settings when used with a DT system. Signed-off-by: Alan Ott a...@signal11.us --- drivers/net/ieee802154/mrf24j40.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c index 3f2c7aa..3106895 100644 --- a/drivers/net/ieee802154/mrf24j40.c +++ b/drivers/net/ieee802154/mrf24j40.c @@ -22,6 +22,7 @@ #include linux/spi/spi.h #include linux/interrupt.h #include linux/module.h +#include linux/pinctrl/consumer.h #include net/wpan-phy.h #include net/mac802154.h @@ -623,6 +624,7 @@ static int mrf24j40_probe(struct spi_device *spi) int ret = -ENOMEM; u8 val; struct mrf24j40 *devrec; + struct pinctrl *pinctrl; printk(KERN_INFO mrf24j40: probe(). IRQ: %d\n, spi-irq); @@ -633,6 +635,11 @@ static int mrf24j40_probe(struct spi_device *spi) if (!devrec-buf) goto err_buf; + pinctrl = devm_pinctrl_get_select_default(spi-dev); + if (IS_ERR(pinctrl)) + dev_warn(spi-dev, + pinctrl pins are not configured from the driver); + spi-mode = SPI_MODE_0; /* TODO: Is this appropriate for right here? */ if (spi-max_speed_hz MAX_SPI_SPEED_HZ) spi-max_speed_hz = MAX_SPI_SPEED_HZ; -- 1.7.11.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 4/4] mrf24j40: Fix byte-order of IEEE address
Load the 64-bit Extended (IEEE) address into the hardware in the proper byte order. Signed-off-by: Alan Ott a...@signal11.us --- drivers/net/ieee802154/mrf24j40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c index b4f9b67..0ca8f88 100644 --- a/drivers/net/ieee802154/mrf24j40.c +++ b/drivers/net/ieee802154/mrf24j40.c @@ -478,7 +478,7 @@ static int mrf24j40_filter(struct ieee802154_dev *dev, int i; for (i = 0; i 8; i++) write_short_reg(devrec, REG_EADR0+i, - filt-ieee_addr[i]); + filt-ieee_addr[7-i]); #ifdef DEBUG printk(KERN_DEBUG Set long addr to: ); -- 1.7.11.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/4] mrf24j40: Increase max SPI speed to 10MHz
Upon consulting the datasheet further, it does indicates a maximum speed
for SCK at 10MHz.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 582c0a3..b4f9b67 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -92,9 +92,8 @@ struct mrf24j40 {
#define MRF24J40_READLONG(reg) (1 15 | (reg) 5)
#define MRF24J40_WRITELONG(reg) (1 15 | (reg) 5 | 1 4)
-/* Maximum speed to run the device at. TODO: Get the real max value from
- * someone at Microchip since it isn't in the datasheet. */
-#define MAX_SPI_SPEED_HZ 100
+/* The datasheet indicates the theoretical maximum for SCK to be 10MHz */
+#define MAX_SPI_SPEED_HZ 1000
#define printdev(X) (X-spi-dev)
--
1.7.11.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 2/4] mrf24j40: Warn if transmit interrupts timeout
Issue a warning if a transmit complete interrupt doesn't happen in time.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 3106895..582c0a3 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -362,6 +362,7 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct
sk_buff *skb)
if (ret == -ERESTARTSYS)
goto err;
if (ret == 0) {
+ dev_warn(printdev(devrec), Timeout waiting for TX
interrupt\n);
ret = -ETIMEDOUT;
goto err;
}
--
1.7.11.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 0/2] Address issues in dma-debug API
Christoph Paasch recently reported a device driver failed to check map error on igb. However after reviewing the code there was no possibility of that. On closer inspection there was a bug in the DMA debug API that was causing the issue. These two patches address the issues I found. The first issue I found while trying to implement a workaround. Specifically the problem is a locking bug which is triggered if a multiple mapped buffer exists and there is not an exact match for the unmap. This results in the CPU becoming deadlocked. The second issue, which was the original problem, is resolved by guaranteeing that if we call dma_mapping_error we set a matching entry to MAP_ERR_CHECKED that was not previously set. I'm not sure if these are critical enough to go into one of the upcoming RC kernels or if these can wait until the merge since this is in a debugging API. I'm leaving that for the sub-maintainers to decide. --- Alexander Duyck (2): dma-debug: Fix locking bug in check_unmap dma-debug: Update DMA debug API to better handle multiple mappings of a buffer lib/dma-debug.c | 42 -- 1 files changed, 28 insertions(+), 14 deletions(-) -- -- 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 0/7] HID: multitouch: support of hybrid finger/pen devices
On Wed, 27 Feb 2013, Benjamin Tissoires wrote: So the solution consists in relying inconditionaly to the quirk MULTI_INPUT for hid-multitouch. Before registering the input device in hid-input, we can test if it has been populated, and if not, then we simply don't register it. In order to prevent a regression for drivers that do not fill the input device, we need to add an other quirk. Hi everybody, I am in progress of reviewing this patchset, and so far don't have any major obejctions; I expect to have the review finished this week, so 3.10 is definitely a realistic target. Just to set my own expectations correctly -- Henrik, are you going to review this patchset as well, or there is no need for me to wait for your feedback? Thanks, -- Jiri Kosina SUSE Labs -- 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 2/2] dma-debug: Update DMA debug API to better handle multiple mappings of a buffer
There were reports of the igb driver unmapping buffers without calling
dma_mapping_error. On closer inspection issues were found in the DMA debug
API and how it handled multiple mappings of the same buffer.
The issue I found is the fact that the debug_dma_mapping_error would only set
the map_err_type to MAP_ERR_CHECKED in the case that the was only one match
for device and device address. However in the case of non-IOMMU, multiple
addresses existed and as a result it was not setting this field once a
second mapping was instantiated. I have resolved this by changing the search
so that it instead will now set MAP_ERR_CHECKED on the first buffer that
matches the device and DMA address that is currently in the state
MAP_ERR_NOT_CHECKED.
A secondary side effect of this patch is that in the case of multiple buffers
using the same address only the last mapping will have a valid map_err_type.
The previous mappings will all end up with map_err_type set to
MAP_ERR_CHECKED because of the dma_mapping_error call in debug_dma_map_page.
However this behavior may be preferable as it means you will likely only see
one real error per multi-mapped buffer, versus the current behavior of
multiple false errors mer multi-mapped buffer.
Signed-off-by: Alexander Duyck alexander.h.du...@intel.com
---
lib/dma-debug.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 724bd4d..aa465d9 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -1082,13 +1082,27 @@ void debug_dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
ref.dev = dev;
ref.dev_addr = dma_addr;
bucket = get_hash_bucket(ref, flags);
- entry = bucket_find_exact(bucket, ref);
- if (!entry)
- goto out;
+ list_for_each_entry(entry, bucket-list, list) {
+ if (!exact_match(ref, entry))
+ continue;
+
+ /*
+* The same physical address can be mapped multiple
+* times. Without a hardware IOMMU this results in the
+* same device addresses being put into the dma-debug
+* hash multiple times too. This can result in false
+* positives being reported. Therefore we implement a
+* best-fit algorithm here which updates the first entry
+* from the hash which fits the reference value and is
+* not currently listed as being checked.
+*/
+ if (entry-map_err_type == MAP_ERR_NOT_CHECKED) {
+ entry-map_err_type = MAP_ERR_CHECKED;
+ break;
+ }
+ }
- entry-map_err_type = MAP_ERR_CHECKED;
-out:
put_hash_bucket(bucket, flags);
}
EXPORT_SYMBOL(debug_dma_mapping_error);
--
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 1/2] dma-debug: Fix locking bug in check_unmap
In check_unmap it is possible to get into a dead-locked state if
dma_mapping_error is called. The problem is that the bucket is locked in
check_unmap, and locked again by debug_dma_mapping_error which is called by
dma_mapping_error. To resolve that we must release the lock on the bucket
before making the call to dma_mapping_error.
Signed-off-by: Alexander Duyck alexander.h.du...@intel.com
---
lib/dma-debug.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 5e396ac..724bd4d 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -862,17 +862,18 @@ static void check_unmap(struct dma_debug_entry *ref)
entry = bucket_find_exact(bucket, ref);
if (!entry) {
+ /* must drop lock before calling dma_mapping_error */
+ put_hash_bucket(bucket, flags);
+
if (dma_mapping_error(ref-dev, ref-dev_addr)) {
err_printk(ref-dev, NULL,
- DMA-API: device driver tries
- to free an invalid DMA memory address\n);
- return;
+ DMA-API: device driver tries to free an
invalid DMA memory address\n);
+ } else {
+ err_printk(ref-dev, NULL,
+ DMA-API: device driver tries to free DMA
memory it has not allocated [device address=0x%016llx] [size=%llu bytes]\n,
+ ref-dev_addr, ref-size);
}
- err_printk(ref-dev, NULL, DMA-API: device driver tries
- to free DMA memory it has not allocated
- [device address=0x%016llx] [size=%llu bytes]\n,
- ref-dev_addr, ref-size);
- goto out;
+ return;
}
if (ref-size != entry-size) {
@@ -936,7 +937,6 @@ static void check_unmap(struct dma_debug_entry *ref)
hash_bucket_del(entry);
dma_entry_free(entry);
-out:
put_hash_bucket(bucket, flags);
}
--
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 5/5] KVM: MMU: fast invalid all mmio sptes
On Fri, Mar 15, 2013 at 8:29 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
This patch tries to introduce a very simple and scale way to invalid all
mmio sptes - it need not walk any shadow pages and hold mmu-lock
KVM maintains a global mmio invalid generation-number which is stored in
kvm-arch.mmio_invalid_gen and every mmio spte stores the current global
generation-number into his available bits when it is created
When KVM need zap all mmio sptes, it just simply increase the global
generation-number. When guests do mmio access, KVM intercepts a MMIO #PF
then it walks the shadow page table and get the mmio spte. If the
generation-number on the spte does not equal the global generation-number,
it will go to the normal #PF handler to update the mmio spte
Since 19 bits are used to store generation-number on mmio spte, the
generation-number can be round after 33554432 times. It is large enough
for nearly all most cases, but making the code be more strong, we zap all
shadow pages when the number is round
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_host.h |2 +
arch/x86/kvm/mmu.c | 61
+--
arch/x86/kvm/mmutrace.h | 17 +++
arch/x86/kvm/paging_tmpl.h |7 +++-
arch/x86/kvm/vmx.c |4 ++
arch/x86/kvm/x86.c |6 +--
6 files changed, 82 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index ef7f4a5..572398e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -529,6 +529,7 @@ struct kvm_arch {
unsigned int n_requested_mmu_pages;
unsigned int n_max_mmu_pages;
unsigned int indirect_shadow_pages;
+ unsigned int mmio_invalid_gen;
Could this get initialized to something close to the wrap-around
value, so that the wrap-around case gets more real-world coverage?
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
/*
* Hash table of struct kvm_mmu_page.
@@ -765,6 +766,7 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
int slot);
void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
struct kvm_memory_slot *slot,
gfn_t gfn_offset, unsigned long mask);
+void kvm_mmu_invalid_mmio_spte(struct kvm *kvm);
void kvm_mmu_zap_all(struct kvm *kvm);
unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int
kvm_nr_mmu_pages);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 13626f4..7093a92 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -234,12 +234,13 @@ static unsigned int get_mmio_spte_generation(u64 spte)
static void mark_mmio_spte(struct kvm *kvm, u64 *sptep, u64 gfn,
unsigned access)
{
- u64 mask = generation_mmio_spte_mask(0);
+ unsigned int gen = ACCESS_ONCE(kvm-arch.mmio_invalid_gen);
+ u64 mask = generation_mmio_spte_mask(gen);
access = ACC_WRITE_MASK | ACC_USER_MASK;
mask |= shadow_mmio_mask | access | gfn PAGE_SHIFT;
- trace_mark_mmio_spte(sptep, gfn, access, 0);
+ trace_mark_mmio_spte(sptep, gfn, access, gen);
mmu_spte_set(sptep, mask);
}
@@ -269,6 +270,34 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep,
gfn_t gfn,
return false;
}
+static bool check_mmio_spte(struct kvm *kvm, u64 spte)
+{
+ return get_mmio_spte_generation(spte) ==
+ ACCESS_ONCE(kvm-arch.mmio_invalid_gen);
+}
+
+/*
+ * The caller should protect concurrent access on
+ * kvm-arch.mmio_invalid_gen. Currently, it is used by
+ * kvm_arch_commit_memory_region and protected by kvm-slots_lock.
+ */
+void kvm_mmu_invalid_mmio_spte(struct kvm *kvm)
+{
+ /* Ensure update memslot has been completed. */
+ smp_mb();
+
+trace_kvm_mmu_invalid_mmio_spte(kvm);
+
+ /*
+* The very rare case: if the generation-number is round,
+* zap all shadow pages.
+*/
+ if (unlikely(kvm-arch.mmio_invalid_gen++ == MAX_GEN)) {
+ kvm-arch.mmio_invalid_gen = 0;
+ return kvm_mmu_zap_all(kvm);
+ }
+}
+
static inline u64 rsvd_bits(int s, int e)
{
return ((1ULL (e - s + 1)) - 1) s;
@@ -3183,9 +3212,12 @@ static u64 walk_shadow_page_get_mmio_spte(struct
kvm_vcpu *vcpu, u64 addr)
}
/*
- * If it is a real mmio page fault, return 1 and emulat the instruction
- * directly, return 0 to let CPU fault again on the address, -1 is
- * returned if bug is detected.
+ * Return value:
+ * 2: invalid spte is detected then let the real page fault path
+ *update the mmio spte.
+ * 1: it is a real mmio page fault, emulate the instruction directly.
+ * 0: let CPU fault again on the
Re: [Patch v1] rtc: fix for the DA9052 rtc device registration
On Fri, 15 Mar 2013 13:59:39 +0530 Ashish Jangam
ashish.jan...@kpitcummins.com wrote:
DA9052/53 MFD core handles only virtual irq therefore rtc driver needs
to be updated to work on virtual irq. Without this update DA9052/53 rtc
driver will fail during its registration.
Also getting irq by it name is no longer supported in DA9052/53 core.
...
--- a/drivers/rtc/rtc-da9052.c
+++ b/drivers/rtc/rtc-da9052.c
@@ -239,10 +239,10 @@ static int da9052_rtc_probe(struct platform_device
*pdev)
rtc-da9052 = dev_get_drvdata(pdev-dev.parent);
platform_set_drvdata(pdev, rtc);
- rtc-irq = platform_get_irq_byname(pdev, ALM);
- ret = request_threaded_irq(rtc-irq, NULL, da9052_rtc_irq,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-ALM, rtc);
+ rtc-irq = DA9052_IRQ_ALARM;
+
+ ret = da9052_request_irq(rtc-da9052, rtc-irq, ALM,
+ da9052_rtc_irq, rtc);
if (ret != 0) {
rtc_err(rtc-da9052, irq registration failed: %d\n, ret);
return ret;
drivers/rtc/rtc-da9052.c was converted to use
devm_request_threaded_irq() after linux-3.8, so I cannot apply this
patch to mainline. Can you please prepare a patch against 3.9-rc3?
Do you believe that the patch should be backported into -stable
kernels? If so, Greg will need a different version of it - ie, the one
you have just sent. Please send that to him at the appropriate time
(say, when you see me drop the 3.9-rc3 version from the -mm tree).
--
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] nohz1: Documentation
On Mon, Mar 18, 2013 at 09:48:31PM +0100, Frederic Weisbecker wrote: 2013/3/18 Rob Landley r...@landley.net: On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote: [ . . . ] +o At least one CPU must keep the scheduling-clock interrupt going + in order to support accurate timekeeping. How? You never said how to tell a processor _not_ to suppress interrupts when CONFIG_THE_OTHER_HALF_OF_NOHZ is enabled. Ah indeed it would be nice to point out that there must be an online CPU outside the value range of the nohz_mask= boot parameter. There's a nohz_mask boot parameter? Yeah we need to document that too. Good catch both of you, fixed! [ . . . ] The system being entirely idle means unnecessary ticks can be dropped. The system having no scheduling decisions to make on a processor also means unnecessary ticks can be dropped. But there are two config options and they get treated as entirely different subsystems... No they share a lot of common infrastructure. Also full dynticks depends on dynticks-idle. Good point, added this. I suppose one of them having a bucket of workarounds and caveats is the reason? One is just let the system behave more efficiently, only reason it's a config option is increased latency waking up from idle can annoy the realtime guys. The second is let the system behave more efficiently in a way that opens up a bunch of sharp edges and requires extensive micromanagement. But those sharp edges seem more unfinished than really a design limitation... The reason of having a seperate Kconfig for the new feature is because it adds some overhead even in the off-case. Good point, added words stating that all of the costs of CONFIG_NO_HZ are also incurred by CONFIG_NO_HZ_FULL. Rob also noted that the presentation of the NOCB Kconfig options and boot parameters was confusing, so I reworked this to put the Kconfig options first (build then boot!) and to indicate that the RCU_NOCB_CPU_NONE, RCU_NOCB_CPU_ZERO, and RCU_NOCB_CPU_ALL options are mutually exclusive. Rob also noted that the current draft is wordy, which I will address in a later draft. Thanx, Paul NO_HZ: Reducing Scheduling-Clock Ticks This document covers Kconfig options and boot parameters used to reduce the number of scheduling-clock interrupts. These reductions can be helpful in improving energy efficiency and in reducing OS jitter, the latter being very important for some types of computationally intensive high-performance computing (HPC) applications and for real-time applications. Within the Linux kernel, there are two major aspects of scheduling-clock interrupt reduction: 1. Idle CPUs. 2. CPUs having only one runnable task. These two cases are described in the following sections. IDLE CPUs If a CPU is idle, there is little point in sending it a scheduling-clock interrupt. After all, the primary purpose of a scheduling-clock interrupt is to force a busy CPU to shift its attention among multiple duties, but an idle CPU by definition has no duties to shift its attention among. The CONFIG_NO_HZ=y Kconfig option causes the kernel to avoid sending scheduling-clock interrupts to idle CPUs, which is critically important both to battery-powered devices and to highly virtualized mainframes. A battery-powered device running a CONFIG_NO_HZ=n kernel would drain its battery very quickly, easily 2-3x as fast as would the same device running a CONFIG_NO_HZ=n kernel. A mainframe running 1,500 OS instances could easily find that half of its CPU time was consumed by scheduling-clock interrupts. In these situations, there is therefore strong motivation to avoid sending scheduling-clock interrupts to idle CPUs. That said, dyntick-idle mode is not free: 1. It increases the number of instructions executed on the path to and from the idle loop. 2. Many architectures will place dyntick-idle CPUs into deep sleep states, which further degrades from-idle transition latencies. Therefore, systems with aggressive real-time response constraints often run CONFIG_NO_HZ=n kernels in order to avoid degrading from-idle transition latencies. An idle CPU that is not receiving scheduling-clock interrupts is said to be dyntick-idle, in dyntick-idle mode, in nohz mode, or running tickless. The remainder of this document will use dyntick-idle mode. There is also a boot parameter nohz= that can be used to disable dyntick-idle mode in CONFIG_NO_HZ=y kernels by specifying nohz=off. By default, CONFIG_NO_HZ=y kernels boot with nohz=on, enabling dyntick-idle mode. CPUs WITH ONLY ONE RUNNABLE TASK If a CPU has only one runnable task, there is again little point in sending it a scheduling-clock interrupt. Recall that the primary purpose of a scheduling-clock interrupt is to force a busy CPU to
Re: [PATCH] mm: Make snapshotting pages for stable writes a per-bio operation
On Fri 15-03-13 16:28:16, Darrick J. Wong wrote:
Walking a bio's page mappings has proved problematic, so create a new bio flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback. Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
PG_writeback set, and set BIO_SNAP_STABLE there. We must also flag journal
metadata bios for stable writeout if data=journal, since file data is
written
through the journal. Finally, the MS_SNAP_STABLE mount flag (only used by
ext3) is now superfluous, so get rid of it.
Signed-off-by: Darrick J. Wong darrick.w...@oracle.com
[darrick.w...@oracle.com: Fold in a couple of small cleanups from akpm]
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/buffer.c |9 -
fs/ext3/super.c |3 ++-
fs/jbd/commit.c | 28 +---
include/linux/blk_types.h |3 ++-
include/linux/buffer_head.h |1 +
include/linux/jbd.h |1 +
include/uapi/linux/fs.h |1 -
mm/bounce.c | 21 +
mm/page-writeback.c |4
9 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..71578d6 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio,
struct buffer_head *bh)
}
}
-int submit_bh(int rw, struct buffer_head * bh)
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
struct bio *bio;
int ret = 0;
@@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
bio-bi_end_io = end_bio_bh_io_sync;
bio-bi_private = bh;
+ bio-bi_flags |= bio_flags;
/* Take care of bh's that straddle the end of the device */
guard_bh_eod(rw, bio, bh);
@@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
bio_put(bio);
return ret;
}
+EXPORT_SYMBOL_GPL(_submit_bh);
+
+int submit_bh(int rw, struct buffer_head *bh)
+{
+ return _submit_bh(rw, bh, 0);
+}
EXPORT_SYMBOL(submit_bh);
/**
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 1d6e2ed..e845b6de 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2063,11 +2063,12 @@ static int ext3_fill_super (struct super_block *sb,
void *data, int silent)
ext3_mark_recovery_complete(sb, es);
ext3_msg(sb, KERN_INFO, recovery complete);
}
+ if (test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA)
+ EXT3_SB(sb)-s_journal-j_flags |= JFS_JOURNALS_DATA;
Sadly this isn't enough. You can have inodes which journal data (there's
an inode flag for this) in data=ordered mode. So what you have to do is to
flag journal_heads (or buffer_heads) as containing journalled data. Or you
can actually use PageChecked flag for this (it is going to be set on all
write-enabled pages with journalled data). But it definitely requires also
some playing with -page_mkwrite() (calling ext3_journal_get_write_access()
from there) and generally I'd rather postpone that to a separate commit. So
just keep it simple and always set the bio flag as you did in the previous
version. I'll write an optimization (mostly because ext4 needs it as well)
and send it to you for testing.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
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] bounce:fix bug, avoid to flush dcache on slab page from jbd2.
On Fri 15-03-13 10:54:41, Darrick J. Wong wrote:
On Fri, Mar 15, 2013 at 11:01:05AM +0100, Jan Kara wrote:
On Thu 14-03-13 15:42:43, Darrick J. Wong wrote:
On Wed, Mar 13, 2013 at 10:02:16PM +0100, Jan Kara wrote:
On Wed 13-03-13 12:44:29, Darrick J. Wong wrote:
On Wed, Mar 13, 2013 at 09:50:21AM +0100, Jan Kara wrote:
On Tue 12-03-13 18:10:20, Darrick J. Wong wrote:
On Tue, Mar 12, 2013 at 03:32:21PM -0700, Andrew Morton wrote:
On Fri, 08 Mar 2013 20:37:36 +0800 Shuge shugeli...@gmail.com
wrote:
The bounce accept slab pages from jbd2, and flush dcache on
them.
When enabling VM_DEBUG, it will tigger VM_BUG_ON in
page_mapping().
So, check PageSlab to avoid it in __blk_queue_bounce().
Bug URL: http://lkml.org/lkml/2013/3/7/56
...
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -214,7 +214,8 @@ static void __blk_queue_bounce(struct
request_queue
*q, struct bio **bio_orig,
if (rw == WRITE) {
char *vto, *vfrom;
- flush_dcache_page(from-bv_page);
+ if (unlikely(!PageSlab(from-bv_page)))
+
flush_dcache_page(from-bv_page);
vto = page_address(to-bv_page) +
to-bv_offset;
vfrom = kmap(from-bv_page) +
from-bv_offset;
memcpy(vto, vfrom, to-bv_len);
I guess this is triggered by Catalin's f1a0c4aa0937975b
(arm64: Cache
maintenance routines), which added a page_mapping() call to
arm64's
arch/arm64/mm/flush.c:flush_dcache_page().
What's happening is that jbd2 is using kmalloc() to allocate
buffer_head
data. That gets submitted down the BIO layer and
__blk_queue_bounce()
calls flush_dcache_page() which in the arm64 case calls
page_mapping()
and page_mapping() does VM_BUG_ON(PageSlab) and splat.
The unusual thing about all of this is that the payload for
some disk
IO is coming from kmalloc, rather than being a user page. It's
oddball
but we've done this for ages and should continue to support it.
Now, the page from kmalloc() cannot be in highmem, so why did
the
bounce code decide to bounce it?
__blk_queue_bounce() does
/*
* is destination page below bounce pfn?
*/
if (page_to_pfn(page) = queue_bounce_pfn(q)
!force)
continue;
and `force' comes from must_snapshot_stable_pages(). But
must_snapshot_stable_pages() must have returned false, because
if it
had returned true then it would have been
must_snapshot_stable_pages()
which went BUG, because must_snapshot_stable_pages() calls
page_mapping().
So my tentative diagosis is that arm64 is fishy. A page which
was
allocated via jbd2_alloc(GFP_NOFS)-kmem_cache_alloc() ended up
being
above arm64's queue_bounce_pfn(). Can you please do a bit of
investigation to work out if this is what is happening? Find
out why
__blk_queue_bounce() decided to bounce a page which shouldn't
have been
bounced?
That sure is strange. I didn't see any obvious reasons why we'd
end up with a
kmalloc above queue_bounce_pfn(). But then I don't have any
arm64s either.
This is all terribly fragile :( afaict if someone sets
bdi_cap_stable_pages_required() against that jbd2 queue, we're
going to
hit that BUG_ON() again, via must_snapshot_stable_pages()'s
page_mapping() call. (Darrick, this means you ;))
Wh. You're right, we shouldn't be calling page_mapping on
slab pages.
We can keep walking the bio segments to find a non-slab page that
can tell us
MS_SNAP_STABLE is set, since we probably won't need the bounce
buffer anyway.
How does something like this look? (+ the patch above)
Umm, this won't quite work. We can have a bio which has just
PageSlab
page attached and so you won't be able to get to the superblock.
Heh, isn't
the whole page_mapping() thing in must_snapshot_stable_pages()
wrong? When we
do direct IO, these pages come directly from userspace and hell
knows where
they come from. Definitely their page_mapping() doesn't give us
anything
useful... Sorry for not realizing this earlier when
Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED
Adding Serge as he is the sometimes capabilities maintainer to this discussion. Casey Schaufler ca...@schaufler-ca.com writes: On 3/18/2013 11:30 AM, Vivek Goyal wrote: On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote: On 3/18/2013 10:05 AM, Vivek Goyal wrote: On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote: On 3/15/2013 1:35 PM, Vivek Goyal wrote: Create a new capability CAP_SIGNED which can be given to signed executables. This would drive anyone who is trying to use capabilities as the privilege mechanism it is intended to be absolutely crazy. Will calling it CAP_SIGNED_SERVICES help. I intend to use it as capability (and not just as a flag for task attribute). No, the name is not the issue. I think primary difference here is that this capability is controlled by kernel and only validly signed processes get it. Applications are allowed to manipulate their capability sets in well defined ways. The behavior of file based capabilities is also explicitly defined. The behavior you are proposing would violate both of these mechanisms. Capabilities aren't just random attribute bits. They indicate that a task has permission to violate a system policy (e.g. change the mode bits of a file the user doesn't own). Think about how this will interact with programs using file based capabilities. It is a separate capability. I am not sure why it would interfere with other capabilities or functionality out there. The behavior of capabilities is uniform. You can't have one capability that behaves differently from the others. If a file is unsigned but has CAP_SIGNED in the file capability set what do you expect to happen? Do you want a signed application to be able to drop and raise the fact that it is signed? I have already removed this capability from bounding set. Behavior I am looking for is that nobody should be able to set CAP_SIGNED as file capability. I will look into that. No! You are not listening. All capabilities work the same way. If the file capabilities say ALL that means ALL. You do not get to put a hole in the middle of the file based capabilities. I am thinking of this more as kernel managed capability. It is not in bounding set of any process and it can not be set as file capability. I heard that. No, you don't get to do that. All capabilities work the same way. Your attribute does not behave the way capabilities do, so you have to implement it some other way. It is a new capability, so no existing user application should be trying to set it. There are (and will be) applications that raise and drop all capabilities, and that do so for good reasons. I think the only surprise would be that they can't drop it. If that's a concern, may be we can allow dropping the capability. But the side affect is that there is no way to gain it back for the life time of process. Right. And that is a change to the capability mechanism. No, you don't get to do that. You don't want a new capability. You want a new attribute that behaves differently than capabilities do. You need to come up with a different way to implement your attribute. You do not get to change the way capabilities work. I expect that you don't want your attribute that indicates that the binary was signed to behave the same way that capabilities do. Like I said, capabilities are not just attribute bits. You need a different kind of process attribute to indicate that the binary was signed. I think I need more than process attribute. One of the things I am looking for is that signed processes run locked in memory and nobody (i think no unsigned process) is able to do ptrace() on it. Using the notion of capability might help here. There are already capabilities associated with ptrace. It would be simple to add a check for signatures in cap_ptrace_access_check. When (if ever) we have multiple LSM support you might consider doing this as a small LSM. Until then, you're going to need a different way to express the signature attribute. I am not sure why you are viewing it as necessarily as attribute only. I am thinking more in terms of that in certain situations, user space processes can't perform certain operations (like kexec) untile and unless process has the capability CAP_SIGNED_SERVICES. And this capability is granted if upon exec() process signature are verified. Sigh. You need the process attribute to make the checks against. The process capability set, uids and groups are all examples of process attributes that exist today. So yes it is little different from how capabilities are managed currently. But is it very hard to extend the current capability definition and include the fact that kernel can give additional capabilities to processes based on some other factors. Yes. That is correct. That is why we have the LSM facility. The unfortunate fact is that you only get one LSM at a time today. I am working on fixing
Re: [PATCH 3/4] writeback: replace custom worker pool implementation with unbound workqueue
On Tue 12-03-13 16:05:10, Jan Kara wrote: On Thu 07-03-13 13:44:08, Tejun Heo wrote: Writeback implements its own worker pool - each bdi can be associated with a worker thread which is created and destroyed dynamically. The worker thread for the default bdi is always present and serves as the forker thread which forks off worker threads for other bdis. there's no reason for writeback to implement its own worker pool when using unbound workqueue instead is much simpler and more efficient. This patch replaces custom worker pool implementation in writeback with an unbound workqueue. I realized there may be one issue - so far we have a clear identification which thread works for which bdi in the thread name (flush-x:y naming). That was useful when debugging things. Now with your worker pool this is lost, am I right? Would it be possible to restore that? Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- 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 3/4] writeback: replace custom worker pool implementation with unbound workqueue
Hello, Jan. On Mon, Mar 18, 2013 at 11:32:44PM +0100, Jan Kara wrote: I realized there may be one issue - so far we have a clear identification which thread works for which bdi in the thread name (flush-x:y naming). That was useful when debugging things. Now with your worker pool this is lost, am I right? Would it be possible to restore that? Unfortunately not directly. It shouldn't be difficult to tell who's working on what from workqueue and writeback tracepoints tho. Thanks. -- tejun -- 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: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 18 Mar 2013, Yinghai Lu wrote: Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost interrupts go away. My understanding from the other mail is that DAniel Vetter already has an idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully this datapoint regarding MSI will fit into it. What is /proc/interrupts difference between with and without pci=nomsi ? drm is forced to share irq 16? Yup, IRQ 16 is being shared, and one of the owners is i915. the vga report strange INTx status... 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 20e4 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Latency: 0 Interrupt: pin A routed to IRQ 44 Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0100c Data: 4142 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 Kernel modules: i915 it should be INTx-, after we have set DisINTx+ in control. So INTx can not be disabled after it get enabled before ? the VGA on my T420 looks right. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21ce Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Thanks Yinghai -- 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] x86: mm: accurate the comments for STEP_SIZE_SHIFT macro
On 03/18/2013 02:19 PM, Yinghai Lu wrote: On Mon, Mar 18, 2013 at 12:14 PM, H. Peter Anvin h...@zytor.com wrote: Instead, try to explain why 5 is the correct value in the current code and how it is (or should be!) derived. initial mapped size is PMD_SIZE, aka 2M. if we use step_size to be PUD_SIZE aka 1G, as most worse case that 1G is cross the 1G boundary, and PG_LEVEL_2M is not set, we will need 1+1+512 pages (aka 2M + 8k) to map 1G range with PTE. So i picked (30-21)/2 to get 5. Please check attached patch. Thanks Yinghai This still seems very opaque. I need to look at it and see if it makes more sense in context. -hpa -- 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] x86, kdump: Set crashkernel_low automatically
On 03/18/2013 02:25 PM, Yinghai Lu wrote: Current code does not set low range for crashkernel if the user does not specify that. That cause regressions on system that does not support intel_iommu properly. Chao said that his system does work well on 3.8 without extra parameter. even iommu does not work with kdump. Set crashkernel_low automatically if the user does not specify that. For system that does support IOMMU with kdump properly, user could specify crashkernel_low=0 to save that 72M low ram. -v3: add swiotlb_size() according to Konrad. Reported-by: WANG Chao chaow...@redhat.com Tested-by: WANG Chao chaow...@redhat.com Signed-off-by: Yinghai Lu ying...@kernel.org Can we get a bit more of an explanation instead of and etc 8M? At least a hint of what kind of objects would go in there... -hpa -- 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] KVM: allow host header to be included even for !CONFIG_KVM
On Thu, Mar 14, 2013 at 05:13:46PM -0700, Kevin Hilman wrote: The new context tracking subsystem unconditionally includes kvm_host.h headers for the guest enter/exit macros. This causes a compile failure when KVM is not enabled. Fix by adding an IS_ENABLED(CONFIG_KVM) check to kvm_host so it can be included/compiled even when KVM is not enabled. Cc: Frederic Weisbecker fweis...@gmail.com Signed-off-by: Kevin Hilman khil...@linaro.org --- Applies on v3.9-rc2 include/linux/kvm_host.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Applied and queued for v3.9, thanks. -- 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: [ 29/75] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Mon, Mar 18, 2013 at 10:35:27PM +0100, Stephane Eranian wrote: On Mon, Mar 18, 2013 at 10:20 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Mar 18, 2013 at 10:11:28PM +0100, Stephane Eranian wrote: On Mon, Mar 18, 2013 at 10:06 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: 3.8-stable review patch. If anyone has any objections, please let me know. Greg, you also need to pick David Rientjes patch to fix compilation on non X86 architectures. What git commit id would that be? I thought I picked up everything that was needed after this one went in, what did I miss? Talking about this particular patch: https://lkml.org/lkml/2013/3/17/183 Don't know if it's in already. Yes, it is. thanks, greg k-h -- 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 2/9] vfs: export do_splice_direct() to modules
On Mon, Mar 18, 2013 at 09:53:34PM +, Al Viro wrote: On Mon, Mar 18, 2013 at 04:39:36PM +0100, Jan Kara wrote: IMO the deadlock is real. In freeze_super() we wait for all writers to the filesystem to finish while blocking beginning of any further writes. So we have a deadlock scenario like: THREAD1 THREAD2 THREAD3 mnt_want_write()mutex_lock(inode-i_mutex); ... freeze_super() block on mutex_lock(inode-i_mutex) sb_wait_write(sb, SB_FREEZE_WRITE); block in sb_start_write() The bug is on fsfreeze side and this is not the only problem related to it. I've missed the implications when I applied fs: Add freezing handling to mnt_want_write() / mnt_drop_write() last June ;-/ The thing is, until then mnt_want_write() used to be a counter; it could be nested. Now any such nesting is a deadlock you've just described. This is seriously wrong, IMO. BTW, having sb_start_write() buried in individual -splice_write() is asking for trouble; could you describe the rules for that? E.g. where does it nest wrt filesystem-private locks? XFS iolock, for example... I'm looking at the existing callers and I really wonder if we ought to push sb_start_write() from -splice_write()/-aio_write()/etc. into the callers. Something like file_start_write()/file_end_write(), with check for file being regular one might be a good starting point. As it is, copyup is really fucked both in unionmount and overlayfs... -- 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] mm: Make snapshotting pages for stable writes a per-bio operation
On Mon, Mar 18, 2013 at 06:41:34PM +0100, Jan Kara wrote:
On Fri 15-03-13 16:28:16, Darrick J. Wong wrote:
Walking a bio's page mappings has proved problematic, so create a new bio
flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback. Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
PG_writeback set, and set BIO_SNAP_STABLE there. We must also flag journal
metadata bios for stable writeout if data=journal, since file data is
written
through the journal. Finally, the MS_SNAP_STABLE mount flag (only used by
ext3) is now superfluous, so get rid of it.
Signed-off-by: Darrick J. Wong darrick.w...@oracle.com
[darrick.w...@oracle.com: Fold in a couple of small cleanups from akpm]
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/buffer.c |9 -
fs/ext3/super.c |3 ++-
fs/jbd/commit.c | 28 +---
include/linux/blk_types.h |3 ++-
include/linux/buffer_head.h |1 +
include/linux/jbd.h |1 +
include/uapi/linux/fs.h |1 -
mm/bounce.c | 21 +
mm/page-writeback.c |4
9 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..71578d6 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio,
struct buffer_head *bh)
}
}
-int submit_bh(int rw, struct buffer_head * bh)
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
struct bio *bio;
int ret = 0;
@@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
bio-bi_end_io = end_bio_bh_io_sync;
bio-bi_private = bh;
+ bio-bi_flags |= bio_flags;
/* Take care of bh's that straddle the end of the device */
guard_bh_eod(rw, bio, bh);
@@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
bio_put(bio);
return ret;
}
+EXPORT_SYMBOL_GPL(_submit_bh);
+
+int submit_bh(int rw, struct buffer_head *bh)
+{
+ return _submit_bh(rw, bh, 0);
+}
EXPORT_SYMBOL(submit_bh);
/**
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 1d6e2ed..e845b6de 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2063,11 +2063,12 @@ static int ext3_fill_super (struct super_block *sb,
void *data, int silent)
ext3_mark_recovery_complete(sb, es);
ext3_msg(sb, KERN_INFO, recovery complete);
}
+ if (test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA)
+ EXT3_SB(sb)-s_journal-j_flags |= JFS_JOURNALS_DATA;
Sadly this isn't enough. You can have inodes which journal data (there's
an inode flag for this) in data=ordered mode. So what you have to do is to
Arrrgh, I forgot that you can do that per-inode. :(
flag journal_heads (or buffer_heads) as containing journalled data. Or you
can actually use PageChecked flag for this (it is going to be set on all
write-enabled pages with journalled data). But it definitely requires also
some playing with -page_mkwrite() (calling ext3_journal_get_write_access()
from there) and generally I'd rather postpone that to a separate commit. So
just keep it simple and always set the bio flag as you did in the previous
version. I'll write an optimization (mostly because ext4 needs it as well)
and send it to you for testing.
Yeah, this is getting a bit complicated for a single patch.
--D
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
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] [trivial] f2fs: Fix typo in comments
Correct spelling typo in comments
Signed-off-by: Masanari Iida standby2...@gmail.com
---
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/gc.c| 2 +-
fs/f2fs/super.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cc2213a..201c8d3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -137,7 +137,7 @@ struct extent_info {
rwlock_t ext_lock; /* rwlock for consistency */
unsigned int fofs; /* start offset in a file */
u32 blk_addr; /* start block address of the extent */
- unsigned int len; /* lenth of the extent */
+ unsigned int len; /* length of the extent */
};
/*
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 94b8a0c..2e3eb2d 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -222,7 +222,7 @@ static unsigned int get_gc_cost(struct f2fs_sb_info *sbi,
unsigned int segno,
}
/*
- * This function is called from two pathes.
+ * This function is called from two paths.
* One is garbage collection and the other is SSR segment selection.
* When it is called during GC, it just gets a victim segment
* and it does not remove it from dirty seglist.
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index fea6e58..62e0177 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -82,7 +82,7 @@ static struct inode *f2fs_alloc_inode(struct super_block *sb)
init_once((void *) fi);
- /* Initilize f2fs-specific inode info */
+ /* Initialize f2fs-specific inode info */
fi-vfs_inode.i_version = 1;
atomic_set(fi-dirty_dents, 0);
fi-i_current_depth = 1;
--
1.8.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 v3] mm: Make snapshotting pages for stable writes a per-bio operation
Walking a bio's page mappings has proved problematic, so create a new bio flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback. Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
PG_writeback set, and set BIO_SNAP_STABLE there. We must also flag journal
metadata bios for stable writeout, since file data can be written through the
journal. Finally, the MS_SNAP_STABLE mount flag (only used by ext3) is now
superfluous, so get rid of it.
Signed-off-by: Darrick J. Wong darrick.w...@oracle.com
[darrick.w...@oracle.com: Fold in a couple of small cleanups from akpm]
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/buffer.c |9 -
fs/ext3/super.c |1 -
fs/jbd/commit.c | 25 ++---
include/linux/blk_types.h |3 ++-
include/linux/buffer_head.h |1 +
include/uapi/linux/fs.h |1 -
mm/bounce.c | 21 +
mm/page-writeback.c |4
8 files changed, 34 insertions(+), 31 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..71578d6 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2949,7 +2949,7 @@ static void guard_bh_eod(int rw, struct bio *bio, struct
buffer_head *bh)
}
}
-int submit_bh(int rw, struct buffer_head * bh)
+int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
struct bio *bio;
int ret = 0;
@@ -2984,6 +2984,7 @@ int submit_bh(int rw, struct buffer_head * bh)
bio-bi_end_io = end_bio_bh_io_sync;
bio-bi_private = bh;
+ bio-bi_flags |= bio_flags;
/* Take care of bh's that straddle the end of the device */
guard_bh_eod(rw, bio, bh);
@@ -2997,6 +2998,12 @@ int submit_bh(int rw, struct buffer_head * bh)
bio_put(bio);
return ret;
}
+EXPORT_SYMBOL_GPL(_submit_bh);
+
+int submit_bh(int rw, struct buffer_head *bh)
+{
+ return _submit_bh(rw, bh, 0);
+}
EXPORT_SYMBOL(submit_bh);
/**
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index fb5120a..3dc48cc 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2067,7 +2067,6 @@ static int ext3_fill_super (struct super_block *sb, void
*data, int silent)
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? journal:
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? ordered:
writeback);
- sb-s_flags |= MS_SNAP_STABLE;
return 0;
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 86b39b1..11bb11f 100644
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -162,8 +162,17 @@ static void journal_do_submit_data(struct buffer_head
**wbuf, int bufs,
for (i = 0; i bufs; i++) {
wbuf[i]-b_end_io = end_buffer_write_sync;
- /* We use-up our safety reference in submit_bh() */
- submit_bh(write_op, wbuf[i]);
+ /*
+* Here we write back pagecache data that may be mmaped. Since
+* we cannot afford to clean the page and set PageWriteback
+* here due to lock ordering (page lock ranks above transaction
+* start), the data can change while IO is in flight. Tell the
+* block layer it should bounce the bio pages if stable data
+* during write is required.
+*
+* We use up our safety reference in submit_bh().
+*/
+ _submit_bh(write_op, wbuf[i], 1 BIO_SNAP_STABLE);
}
}
@@ -667,7 +676,17 @@ start_journal_io:
clear_buffer_dirty(bh);
set_buffer_uptodate(bh);
bh-b_end_io = journal_end_buffer_io_sync;
- submit_bh(write_op, bh);
+ /*
+* In data=journal mode, here we can end up
+* writing pagecache data that might be
+* mmapped. Since we can't afford to clean the
+* page and set PageWriteback (see the comment
+* near the other use of _submit_bh()), the
+* data can change while the write is in
+* flight. Tell the block layer to bounce the
+* bio pages if stable pages are required.
+*/
+ _submit_bh(write_op, bh, 1 BIO_SNAP_STABLE);
}
cond_resched();
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index cdf1119..22990cf 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -111,12 +111,13 @@ struct bio {
#define BIO_FS_INTEGRITY 9 /* fs owns integrity data,
Re: [PATCH] usb: Make USB persist default configurable
On Wed, Mar 13, 2013 at 03:57:31PM -0700, Julius Werner wrote: Commit 9214d1d8 set the USB persist flag as a default for all devices. This might be desirable for some distributions, but it certainly has its trade-offs... most importantly, it can significantly increase system resume time, because the kernel blocks on resuming (and sometimes resetting) USB devices before it unfreezes userspace. This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST, which allows distributions to make this decision on their own without the need to carry a custom patch or revert the kernel's setting in userspace. Why can't you just revert this in userspace? Isn't that easier than doing a kernel patch and providing an option that we need to now maintain for pretty much forever? thanks, greg k-h -- 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 4/7] n_tty: Encapsulate minimum_to_wake within N_TTY
On Wed, Mar 06, 2013 at 08:38:22AM -0500, Peter Hurley wrote: minimum_to_wake is unique to N_TTY processing, and belongs in per-ldisc data. Add the ldisc method, ldisc_ops::fasync(), to notify line disciplines when signal-driven I/O is enabled or disabled. When enabled for N_TTY (by fcntl(F_SETFL, O_ASYNC)), blocking reader/polls will be woken for any readable input. When disabled, blocking reader/polls are not woken until the read buffer is full. Canonical mode (L_ICANON(tty), n_tty_data::icanon) is not affected by the minimum_to_wake setting. Signed-off-by: Peter Hurley pe...@hurleysoftware.com For some reason, this patch doesn't apply. Care to refresh this one, and the rest in this series, and resend? thanks, greg k-h -- 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 05/16] TTY: add tty_port_tty_wakeup helper
On Fri, Mar 08, 2013 at 08:02:09PM +0100, Jiri Slaby wrote: On 03/08/2013 04:02 PM, Peter Hurley wrote: On Thu, 2013-03-07 at 13:12 +0100, Jiri Slaby wrote: It allows for cleaning up on a considerable amount of places. They did port_get, wakeup, kref_put. Now the only thing needed is to call tty_port_tty_wakeup which does exactly that. One exception is ifx6x60 where tty_wakeup was open-coded. We now call tty_wakeup properly there. Signed-off-by: Jiri Slaby jsl...@suse.cz --- arch/um/drivers/line.c | 8 +--- Cc: Jeff Dike jd...@addtoit.com Cc: Richard Weinberger rich...@nod.at drivers/isdn/capi/capi.c| 7 +-- Cc: Karsten Keil i...@linux-pingi.de drivers/isdn/gigaset/interface.c| 6 +- Cc: Hansjoerg Lipp hjl...@web.de Cc: Tilman Schmidt til...@imap.cc Cc: gigaset307x-com...@lists.sourceforge.net Cc: net...@vger.kernel.org drivers/net/usb/hso.c | 13 ++--- Cc: Jan Dumon j.du...@option.com Cc: linux-...@vger.kernel.org drivers/s390/char/sclp_tty.c| 9 ++--- drivers/s390/char/sclp_vt220.c | 8 +--- Cc: Martin Schwidefsky schwidef...@de.ibm.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: linux...@de.ibm.com Cc: linux-s...@vger.kernel.org drivers/staging/fwserial/fwserial.c | 10 ++ Cc: Me :) drivers/staging/serqt_usb2/serqt_usb2.c | 7 +-- Cc: YAMANE Toshiaki yamaneto...@gmail.com Cc: Devendra Naga devendra.a...@gmail.com and so on... Same for the other mega-patches. I'm not sure whether to CC all the people for such patches. I always tended not to and instead rely on people reading LKML :P. If this is the preferred way, I of course can do it next time. It's nice to at least cc: driver maintainers if you can, you can script get_maintainers.pl to do this for you. But don't worry about it this time. thanks, greg k-h -- 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] sgy-cts1000: Remove __dev* attributes
Somehow the driver snuck in with these still in it.
Signed-off-by: Ben Collins be...@servergy.com
---
arch/powerpc/platforms/85xx/sgy_cts1000.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/sgy_cts1000.c
b/arch/powerpc/platforms/85xx/sgy_cts1000.c
index 611e92f..7179726 100644
--- a/arch/powerpc/platforms/85xx/sgy_cts1000.c
+++ b/arch/powerpc/platforms/85xx/sgy_cts1000.c
@@ -69,7 +69,7 @@ static irqreturn_t gpio_halt_irq(int irq, void *__data)
return IRQ_HANDLED;
};
-static int __devinit gpio_halt_probe(struct platform_device *pdev)
+static int gpio_halt_probe(struct platform_device *pdev)
{
enum of_gpio_flags flags;
struct device_node *node = pdev-dev.of_node;
@@ -128,7 +128,7 @@ static int __devinit gpio_halt_probe(struct platform_device
*pdev)
return 0;
}
-static int __devexit gpio_halt_remove(struct platform_device *pdev)
+static int gpio_halt_remove(struct platform_device *pdev)
{
if (halt_node) {
int gpio = of_get_gpio(halt_node, 0);
@@ -165,7 +165,7 @@ static struct platform_driver gpio_halt_driver = {
.of_match_table = gpio_halt_match,
},
.probe = gpio_halt_probe,
- .remove = __devexit_p(gpio_halt_remove),
+ .remove = gpio_halt_remove,
};
module_platform_driver(gpio_halt_driver);
--
1.8.1.2
--
Servergy : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu: http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.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 1/3] rbtree_test: use pr_info for module prefix in messages
This provides nicer message output. Since it seems more appropriate
for the nature of this module, also use KERN_INFO instead of other
levels.
Signed-off-by: Davidlohr Bueso davidlohr.bu...@hp.com
---
lib/rbtree_test.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index af38aed..66ca26d 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -1,3 +1,6 @@
+#define KMSG_COMPONENT rbtree_test
+#define pr_fmt(fmt) KMSG_COMPONENT : fmt
+
#include linux/module.h
#include linux/rbtree_augmented.h
#include linux/random.h
@@ -153,7 +156,7 @@ static int rbtree_test_init(void)
int i, j;
cycles_t time1, time2, time;
- printk(KERN_ALERT rbtree testing);
+ pr_info(rbtree testing);
prandom_seed_state(rnd, 3141592653589793238ULL);
init();
@@ -171,7 +174,7 @@ static int rbtree_test_init(void)
time = time2 - time1;
time = div_u64(time, PERF_LOOPS);
- printk( - %llu cycles\n, (unsigned long long)time);
+ pr_info( - %llu cycles\n, (unsigned long long)time);
for (i = 0; i CHECK_LOOPS; i++) {
init();
@@ -186,7 +189,7 @@ static int rbtree_test_init(void)
check(0);
}
- printk(KERN_ALERT augmented rbtree testing);
+ pr_info(augmented rbtree testing);
init();
@@ -203,7 +206,7 @@ static int rbtree_test_init(void)
time = time2 - time1;
time = div_u64(time, PERF_LOOPS);
- printk( - %llu cycles\n, (unsigned long long)time);
+ pr_info( - %llu cycles\n, (unsigned long long)time);
for (i = 0; i CHECK_LOOPS; i++) {
init();
@@ -223,7 +226,7 @@ static int rbtree_test_init(void)
static void rbtree_test_exit(void)
{
- printk(KERN_ALERT test exit\n);
+ pr_info(test exit\n);
}
module_init(rbtree_test_init)
--
1.7.11.7
--
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/3] rbtree_test: add more rbtree integrity checks
When checking the rbtree, account for more properties:
- Both children of a red node are black.
- The tree has at least 2**bh(v)-1 internal nodes.
Signed-off-by: Davidlohr Bueso davidlohr.bu...@hp.com
---
lib/rbtree_test.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 0fea14e..4c84f85 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -106,7 +106,7 @@ static void init(void)
static bool is_red(struct rb_node *rb)
{
- return !(rb-__rb_parent_color 1);
+ return rb ? !(rb-__rb_parent_color RB_BLACK) : 0;
}
static int black_path_count(struct rb_node *rb)
@@ -120,24 +120,38 @@ static int black_path_count(struct rb_node *rb)
static void check(int nr_nodes)
{
struct rb_node *rb;
- int count = 0;
- int blacks = 0;
+ int blacks = 0, count = 0;
u32 prev_key = 0;
for (rb = rb_first(root); rb; rb = rb_next(rb)) {
struct test_node *node = rb_entry(rb, struct test_node, rb);
+
+ /* sorted keys */
WARN_ON_ONCE(node-key prev_key);
- WARN_ON_ONCE(is_red(rb)
-(!rb_parent(rb) || is_red(rb_parent(rb;
+
+ if (is_red(rb)) {
+ /*
+* root must be black and no path contains two
+* consecutive red nodes.
+*/
+ WARN_ON_ONCE(!rb_parent(rb) || is_red(rb_parent(rb)));
+
+ /* both children of a red node are black */
+ WARN_ON_ONCE(is_red(rb-rb_left) ||
is_red(rb-rb_right));
+ }
+
if (!count)
blacks = black_path_count(rb);
else
WARN_ON_ONCE((!rb-rb_left || !rb-rb_right)
blacks != black_path_count(rb));
+
prev_key = node-key;
count++;
}
+
WARN_ON_ONCE(count != nr_nodes);
+ WARN_ON_ONCE(count (1 black_path_count(rb_last(root))) - 1);
}
static void check_augmented(int nr_nodes)
--
1.7.11.7
--
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 2/3] rbtree_test: add __init/__exit annotations
Signed-off-by: Davidlohr Bueso davidlohr.bu...@hp.com
---
lib/rbtree_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 66ca26d..0fea14e 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -151,7 +151,7 @@ static void check_augmented(int nr_nodes)
}
}
-static int rbtree_test_init(void)
+static int __init rbtree_test_init(void)
{
int i, j;
cycles_t time1, time2, time;
@@ -224,7 +224,7 @@ static int rbtree_test_init(void)
return -EAGAIN; /* Fail will directly unload the module */
}
-static void rbtree_test_exit(void)
+static void __exit rbtree_test_exit(void)
{
pr_info(test exit\n);
}
--
1.7.11.7
--
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] x86, kdump: Set crashkernel_low automatically
On Mon, Mar 18, 2013 at 3:52 PM, H. Peter Anvin h...@zytor.com wrote: On 03/18/2013 02:25 PM, Yinghai Lu wrote: Current code does not set low range for crashkernel if the user does not specify that. That cause regressions on system that does not support intel_iommu properly. Chao said that his system does work well on 3.8 without extra parameter. even iommu does not work with kdump. Set crashkernel_low automatically if the user does not specify that. For system that does support IOMMU with kdump properly, user could specify crashkernel_low=0 to save that 72M low ram. -v3: add swiotlb_size() according to Konrad. Reported-by: WANG Chao chaow...@redhat.com Tested-by: WANG Chao chaow...@redhat.com Signed-off-by: Yinghai Lu ying...@kernel.org Can we get a bit more of an explanation instead of and etc 8M? At least a hint of what kind of objects would go in there... now only have: swiotlb overflow buffer v_overflow_buffer = alloc_bootmem_low_pages_nopanic( PAGE_ALIGN(io_tlb_overflow)); and /* * When the IOMMU overflows we return a fallback buffer. This sets the size. */ static unsigned long io_tlb_overflow = 32*1024; so it is 32K, and I round it to 8M. -- 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 0/6] TTY: port hangup and close fixes
On Thu, Mar 07, 2013 at 03:55:47PM +0100, Johan Hovold wrote: These patches against 3.9-rc1 fix a few issues with tty-port hangup and close. all now applied, thanks. greg k-h -- 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: [ 04/21] target/pscsi: Fix page increment
On Mon, 2013-03-18 at 14:00 -0700, Nicholas A. Bellinger wrote:
On Mon, 2013-03-18 at 13:35 +0800, Asias He wrote:
On Sat, Mar 16, 2013 at 02:10:22AM +, Ben Hutchings wrote:
On Tue, 2013-03-12 at 15:44 -0700, Greg Kroah-Hartman wrote:
3.0-stable review patch. If anyone has any objections, please let me
know.
--
From: Asias He as...@redhat.com
commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.
The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page
address if the 'while (len 0 data_len 0) { ... }' loop is
executed more than one once.
Signed-off-by: Asias He as...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/target/target_core_pscsi.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1210,7 +1210,6 @@ static int __pscsi_map_task_SG(
bio = NULL;
}
- page++;
len -= bytes;
data_len -= bytes;
off = 0;
So in case a fragment crosses a page boundary, we wrap around to the
beginning of the same page? That doesn't look right.
If the fragment crosses a page boundary, what is the correct page
for it?
Nicholas, can we assume sg-length + sg-offset should be less than
PAGE_SIZE here?
sg-length + sg-offset can be less than or equal to PAGE_SIZE here.
For everything other than tcm_loop + tcm_vhost using externally
allocated SGLs, we can expect fragments to never cross the page
boundary.
For tcm_loop + tcm_vhost, there are a few special cases with control CDB
paylaods (usually going through scsi-generic) where we can have a non
zero sg-offset, but at least in the cases I've seen this is still not
using SGL elements that exceed PAGE_SIZE.
So, I think this logic is OK for SGLs that cross page boundries, given
that it's done outside of the inner loop where *page is set during each
for_each_sg().
The page is set using sg_page() in the outer loop and was then
incremented in the inner loop.
for_each_sg(sgl, sg, sgl_nents, i) {
page = sg_page(sg);
off = sg-offset;
len = sg-length;
while (len 0 data_len 0) {
bytes = min_t(unsigned int, len, PAGE_SIZE - off);
bytes = min(bytes, data_len);
...
/* page++; */
len -= bytes;
data_len -= bytes;
off = 0;
}
}
The inner loop is apparently meant to iterate over pages of a segment,
but is now just wrapping around a single page.
The case where this logic is broken, and that the 'page
++' was addressing is when sg-length PAGE_SIZE.
That is a sufficient but not a necessary condition for the increment.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/2] regmap: core: Split out in place value parsing
On 03/03/2013 06:14 PM, Mark Brown wrote: Currently the value parsing operations both return the parsed value and modify the passed buffer. This precludes their use in places like the cache code so split out the in place modification into a new parse_inplace() operation. Mark, This change seems to break audio on my Tegra system with a WM8903 CODEC. In next-20130318, reverting this plus regmap: cache: Store caches in native register format where possible which depends on it does solve the problem. Looking at the raw WM8903 registers using i2cdump shows that for example without these patches, register 39h is set to 0x0020, but with them it's set to 0x0021, so the headphones are muted. In both cases, the regmap debugfs file thinks the value last written is 0xa1 (the 0x80 bit isn't actually state stored in HW, so the only relevant difference is in the LSB). There are numerous other differences in i2cdump output. It took a very quick look at the patch and couldn't see anything actively wrong. I wonder if one of the existing unconverted users of .parse_val() relies on the in-place modification of the buffer as well as getting the result back, and so should have been converted to calling both .parse_inplace() and then .parse_val()? -- 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 1/3] rbtree_test: use pr_info for module prefix in messages
On Mon, 2013-03-18 at 16:20 -0700, Davidlohr Bueso wrote: This provides nicer message output. Since it seems more appropriate for the nature of this module, also use KERN_INFO instead of other levels. [] diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c [] @@ -153,7 +156,7 @@ static int rbtree_test_init(void) int i, j; cycles_t time1, time2, time; - printk(KERN_ALERT rbtree testing); + pr_info(rbtree testing); prandom_seed_state(rnd, 3141592653589793238ULL); init(); @@ -171,7 +174,7 @@ static int rbtree_test_init(void) time = time2 - time1; time = div_u64(time, PERF_LOOPS); - printk( - %llu cycles\n, (unsigned long long)time); + pr_info( - %llu cycles\n, (unsigned long long)time); You change the output here by more than just adding a prefix. The first printk didn't have a newline. The old code would print: rbtree testing - foo cycles The new code prints: rbtree_test: rbtree testing rbtree_test: - foo cycles btw: each pr_info should have a newline termination or be followed by a some number of pr_cont/printk with the last one having a terminating newline. The first pr_info here doesn't have a newline so it's possible (though unlikely) that another thread could have its output appended/interleaved on the same line. -- 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 1/3] rbtree_test: use pr_info for module prefix in messages
On Mon, 2013-03-18 at 16:44 -0700, Joe Perches wrote: On Mon, 2013-03-18 at 16:20 -0700, Davidlohr Bueso wrote: This provides nicer message output. Since it seems more appropriate for the nature of this module, also use KERN_INFO instead of other levels. [] diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c [] @@ -153,7 +156,7 @@ static int rbtree_test_init(void) int i, j; cycles_t time1, time2, time; - printk(KERN_ALERT rbtree testing); + pr_info(rbtree testing); prandom_seed_state(rnd, 3141592653589793238ULL); init(); @@ -171,7 +174,7 @@ static int rbtree_test_init(void) time = time2 - time1; time = div_u64(time, PERF_LOOPS); - printk( - %llu cycles\n, (unsigned long long)time); + pr_info( - %llu cycles\n, (unsigned long long)time); You change the output here by more than just adding a prefix. The first printk didn't have a newline. The old code would print: rbtree testing - foo cycles The new code prints: rbtree_test: rbtree testing rbtree_test: - foo cycles Ah, I see. This is actually the first time I'm using pr_* calls. I actually don't mind the new format, it looked ok, but if others don't agree, I can always resend it. btw: each pr_info should have a newline termination or be followed by a some number of pr_cont/printk with the last one having a terminating newline. The first pr_info here doesn't have a newline so it's possible (though unlikely) that another thread could have its output appended/interleaved on the same line. -- 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 v5 00/44] ldisc patchset
On Mon, Mar 11, 2013 at 04:44:20PM -0400, Peter Hurley wrote: Greg, This patchset includes 'tty: Drop lock contention stat from ldsem trylocks' so no need to apply that on this series. Also, I noticed you kept the 'tty is NULL' removal on a different branch so I left my patch in this series that removes it. This series applies cleanly to tty-next. I've applied the first 25 patches, right up to the create a new lock patch. I'll comment on that one next. thanks, greg k-h -- 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] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
It is possible for one thread to to take se_sess-sess_cmd_lock in
core_tmr_abort_task() before taking a reference count on
se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops
se_cmd-cmd_kref before taking se_sess-sess_cmd_lock.
This introduces kref_put_and_lock() and uses it in
target_put_sess_cmd() to close the race window.
Signed-off-by: Joern Engel jo...@logfs.org
---
drivers/target/target_core_transport.c | 17 +++--
include/linux/kref.h | 26 ++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 04ec9cb..2b8277c 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2207,21 +2207,19 @@ static void target_release_cmd_kref(struct kref *kref)
{
struct se_cmd *se_cmd = container_of(kref, struct se_cmd, cmd_kref);
struct se_session *se_sess = se_cmd-se_sess;
- unsigned long flags;
- spin_lock_irqsave(se_sess-sess_cmd_lock, flags);
if (list_empty(se_cmd-se_cmd_list)) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
return;
}
if (se_sess-sess_tearing_down se_cmd-cmd_wait_set) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
complete(se_cmd-cmd_wait_comp);
return;
}
list_del(se_cmd-se_cmd_list);
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
}
@@ -2232,7 +2230,14 @@ static void target_release_cmd_kref(struct kref *kref)
*/
int target_put_sess_cmd(struct se_session *se_sess, struct se_cmd *se_cmd)
{
- return kref_put(se_cmd-cmd_kref, target_release_cmd_kref);
+ unsigned long flags;
+ int ret;
+
+ local_irq_save(flags);
+ ret = kref_put_and_lock(se_cmd-cmd_kref, target_release_cmd_kref,
+ se_sess-sess_cmd_lock);
+ local_irq_restore(flags);
+ return ret;
}
EXPORT_SYMBOL(target_put_sess_cmd);
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 4972e6e..bc4dbc1 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -19,6 +19,7 @@
#include linux/atomic.h
#include linux/kernel.h
#include linux/mutex.h
+#include linux/spinlock_types.h
struct kref {
atomic_t refcount;
@@ -95,6 +96,31 @@ static inline int kref_put(struct kref *kref, void
(*release)(struct kref *kref)
return kref_sub(kref, 1, release);
}
+/**
+ * kref_put_and_lock - decrement refcount for object.
+ * @kref: object.
+ * @release: pointer to the function that will clean up the object when the
+ * last reference to the object is released.
+ * This pointer is required, and it is not acceptable to pass kfree
+ * in as this function.
+ * @lock: lock to take in release case
+ *
+ * Behaves identical to kref_put with one exception. If the reference count
+ * drops to zero, the lock will be taken atomically wrt dropping the reference
+ * count.
+ */
+static inline int kref_put_and_lock(struct kref *kref,
+ void (*release)(struct kref *kref),
+ spinlock_t *lock)
+{
+ WARN_ON(release == NULL);
+ if (atomic_dec_and_lock(kref-refcount, lock)) {
+ release(kref);
+ return 1;
+ }
+ return 0;
+}
+
static inline int kref_put_mutex(struct kref *kref,
void (*release)(struct kref *kref),
struct mutex *lock)
--
1.7.10.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/
Re: [PATCH] [media] ir: IR_RX51 only works on OMAP2
Em Thu, 14 Mar 2013 22:56:44 +0100 Arnd Bergmann a...@arndb.de escreveu: This driver can be enabled on OMAP1 at the moment, which breaks allyesconfig for that platform. Let's mark it OMAP2PLUS-only in Kconfig, since that is the only thing it builds on. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Timo Kokkonen timo.t.kokko...@iki.fi Cc: Tony Lindgren t...@atomide.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: linux-me...@vger.kernel.org --- Mauro, please apply for 3.9 OK, I'm applying it on my 3.9 branch right now. Thanks! Mauro -- 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 v5 26/44] tty: Add read-recursive, writer-prioritized rw semaphore
On Mon, Mar 11, 2013 at 04:44:46PM -0400, Peter Hurley wrote: The semantics of a rw semaphore are almost ideally suited for tty line discipline lifetime management; multiple active threads obtain references (read locks) while performing i/o to prevent the loss or change of the current line discipline (write lock). Unfortunately, the existing rw_semaphore is ill-suited in other ways; 1) obtaining a reference can be recursive, ie., a reference holder may attempt to obtain another reference. Recursive read locks are not supported by rwsem. Why does a ldisc need to obtain this recursively? 2) TIOCSETD ioctl (change line discipline) expects to return an error if the line discipline cannot be exclusively locked within 5 secs. Lock wait timeouts are not supported by rwsem. Don't we have some other lock that can timeout? 3) A tty hangup is expected to halt and scrap pending i/o, so exclusive locking must be prioritized without precluding existing reference holders from obtaining recursive read locks. Writer priority is not supported by rwsem. But how bad is it really if we have to wait a bit for that write lock to get through all of the existing readers? Either way, we are supposed to be dropping i/o, so it shouldn't be a big deal, right? Add ld_semaphore which implements these requirements in a semantically and operationally similar way to rw_semaphore. I _really_ don't want to add a new lock to the kernel, especially one that is only used by one driver. You are going to have to convince the current lock authors that this really is needed, before I can take it, sorry. What is wrong with the existing ldisc code that the creation of this lock is needed? Is our current code that broken? Ok, it is the tty layer, so it probably is, but it's made it this far for the past 20 years... greg k-h -- 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 v5 28/44] tty: Remove ldsem recursion support
On Mon, Mar 11, 2013 at 04:44:48PM -0400, Peter Hurley wrote: Read lock recursion is no longer required for ldisc references; remove mechanism. Signed-off-by: Peter Hurley pe...@hurleysoftware.com --- drivers/tty/tty_ldsem.c | 83 +-- include/linux/tty_ldisc.h | 2 -- 2 files changed, 8 insertions(+), 77 deletions(-) Wait, why did you add something 3 patches ago, only to remove it here? Why not just smush these patches together in the first place? greg k-h -- 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 03/10] mm: vmscan: Flatten kswapd priority loop
Hi Mel,
On 03/17/2013 09:04 PM, Mel Gorman wrote:
kswapd stops raising the scanning priority when at least SWAP_CLUSTER_MAX
pages have been reclaimed or the pgdat is considered balanced. It then
rechecks if it needs to restart at DEF_PRIORITY and whether high-order
reclaim needs to be reset. This is not wrong per-se but it is confusing
to follow and forcing kswapd to stay at DEF_PRIORITY may require several
restarts before it has scanned enough pages to meet the high watermark even
at 100% efficiency. This patch irons out the logic a bit by controlling
when priority is raised and removing the goto loop_again.
This patch has kswapd raise the scanning priority until it is scanning
enough pages that it could meet the high watermark in one shrink of the
LRU lists if it is able to reclaim at 100% efficiency. It will not raise
the scanning prioirty higher unless it is failing to reclaim any pages.
To avoid infinite looping for high-order allocation requests kswapd will
not reclaim for high-order allocations when it has reclaimed at least
twice the number of pages as the allocation request.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/vmscan.c | 86 ++---
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 182ff15..279d0c2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2625,8 +2625,11 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int
order, long remaining,
/*
* kswapd shrinks the zone by the number of pages required to reach
* the high watermark.
+ *
+ * Returns true if kswapd scanned at least the requested number of
+ * pages to reclaim.
*/
-static void kswapd_shrink_zone(struct zone *zone,
+static bool kswapd_shrink_zone(struct zone *zone,
struct scan_control *sc,
unsigned long lru_pages)
{
@@ -2646,6 +2649,8 @@ static void kswapd_shrink_zone(struct zone *zone,
if (nr_slab == 0 !zone_reclaimable(zone))
zone-all_unreclaimable = 1;
+
+ return sc-nr_scanned = sc-nr_to_reclaim;
}
/*
@@ -2672,26 +2677,25 @@ static void kswapd_shrink_zone(struct zone *zone,
static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
int *classzone_idx)
{
- bool pgdat_is_balanced = false;
int i;
int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
unsigned long nr_soft_reclaimed;
unsigned long nr_soft_scanned;
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
+ .priority = DEF_PRIORITY,
.may_unmap = 1,
.may_swap = 1,
+ .may_writepage = !laptop_mode,
What's the influence of this change? If there are large numbers of
anonymous pages and very little file pages, anonymous pages will not be
swapped out when priorty = DEF_PRIORITY-2. Just no sense scan.
.order = order,
.target_mem_cgroup = NULL,
};
-loop_again:
- sc.priority = DEF_PRIORITY;
- sc.nr_reclaimed = 0;
- sc.may_writepage = !laptop_mode;
count_vm_event(PAGEOUTRUN);
do {
unsigned long lru_pages = 0;
+ unsigned long nr_reclaimed = sc.nr_reclaimed;
+ bool raise_priority = true;
/*
* Scan in the highmem-dma direction for the highest
@@ -2733,10 +2737,8 @@ loop_again:
}
}
- if (i 0) {
- pgdat_is_balanced = true;
+ if (i 0)
goto out;
- }
for (i = 0; i = end_zone; i++) {
struct zone *zone = pgdat-node_zones + i;
@@ -2803,8 +2805,16 @@ loop_again:
if ((buffer_heads_over_limit is_highmem_idx(i)) ||
!zone_balanced(zone, testorder,
- balance_gap, end_zone))
- kswapd_shrink_zone(zone, sc, lru_pages);
+ balance_gap, end_zone)) {
+ /*
+* There should be no need to raise the
+* scanning priority if enough pages are
+* already being scanned that that high
+* watermark would be met at 100% efficiency.
+*/
+ if (kswapd_shrink_zone(zone, sc, lru_pages))
+ raise_priority = false;
+ }
/*
* If we're getting trouble reclaiming, start doing
@@ -2839,46 +2849,33 @@ loop_again:
pfmemalloc_watermark_ok(pgdat))
wake_up(pgdat-pfmemalloc_wait);
- if (pgdat_balanced(pgdat, order,
Re: [PATCH 01/10] mm: vmscan: Limit the number of pages kswapd reclaims at each priority
Hi Mel,
On 03/17/2013 09:04 PM, Mel Gorman wrote:
The number of pages kswapd can reclaim is bound by the number of pages it
scans which is related to the size of the zone and the scanning priority. In
many cases the priority remains low because it's reset every SWAP_CLUSTER_MAX
reclaimed pages but in the event kswapd scans a large number of pages it
cannot reclaim, it will raise the priority and potentially discard a large
percentage of the zone as sc-nr_to_reclaim is ULONG_MAX. The user-visible
effect is a reclaim spike where a large percentage of memory is suddenly
freed. It would be bad enough if this was just unused memory but because
Since there is nr_reclaimed = nr_to_reclaim check if priority is large
than DEF_PRIORITY in shrink_lruvec, how can a large percentage of memory
is suddenly freed happen?
of how anon/file pages are balanced it is possible that applications get
pushed to swap unnecessarily.
This patch limits the number of pages kswapd will reclaim to the high
watermark. Reclaim will will overshoot due to it not being a hard limit as
shrink_lruvec() will ignore the sc.nr_to_reclaim at DEF_PRIORITY but it
prevents kswapd reclaiming the world at higher priorities. The number of
pages it reclaims is not adjusted for high-order allocations as kswapd will
reclaim excessively if it is to balance zones for high-order allocations.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/vmscan.c | 53 +
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 88c5fed..4835a7a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2593,6 +2593,32 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int
order, long remaining,
}
/*
+ * kswapd shrinks the zone by the number of pages required to reach
+ * the high watermark.
+ */
+static void kswapd_shrink_zone(struct zone *zone,
+ struct scan_control *sc,
+ unsigned long lru_pages)
+{
+ unsigned long nr_slab;
+ struct reclaim_state *reclaim_state = current-reclaim_state;
+ struct shrink_control shrink = {
+ .gfp_mask = sc-gfp_mask,
+ };
+
+ /* Reclaim above the high watermark. */
+ sc-nr_to_reclaim = max(SWAP_CLUSTER_MAX, high_wmark_pages(zone));
+ shrink_zone(zone, sc);
+
+ reclaim_state-reclaimed_slab = 0;
+ nr_slab = shrink_slab(shrink, sc-nr_scanned, lru_pages);
+ sc-nr_reclaimed += reclaim_state-reclaimed_slab;
+
+ if (nr_slab == 0 !zone_reclaimable(zone))
+ zone-all_unreclaimable = 1;
+}
+
+/*
* For kswapd, balance_pgdat() will work across all this node's zones until
* they are all at high_wmark_pages(zone).
*
@@ -2619,27 +2645,16 @@ static unsigned long balance_pgdat(pg_data_t *pgdat,
int order,
bool pgdat_is_balanced = false;
int i;
int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
- unsigned long total_scanned;
- struct reclaim_state *reclaim_state = current-reclaim_state;
unsigned long nr_soft_reclaimed;
unsigned long nr_soft_scanned;
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
.may_unmap = 1,
.may_swap = 1,
- /*
-* kswapd doesn't want to be bailed out while reclaim. because
-* we want to put equal scanning pressure on each zone.
-*/
- .nr_to_reclaim = ULONG_MAX,
.order = order,
.target_mem_cgroup = NULL,
};
- struct shrink_control shrink = {
- .gfp_mask = sc.gfp_mask,
- };
loop_again:
- total_scanned = 0;
sc.priority = DEF_PRIORITY;
sc.nr_reclaimed = 0;
sc.may_writepage = !laptop_mode;
@@ -2710,7 +2725,7 @@ loop_again:
*/
for (i = 0; i = end_zone; i++) {
struct zone *zone = pgdat-node_zones + i;
- int nr_slab, testorder;
+ int testorder;
unsigned long balance_gap;
if (!populated_zone(zone))
@@ -2730,7 +2745,6 @@ loop_again:
order, sc.gfp_mask,
nr_soft_scanned);
sc.nr_reclaimed += nr_soft_reclaimed;
- total_scanned += nr_soft_scanned;
/*
* We put equal pressure on every zone, unless
@@ -2759,17 +2773,8 @@ loop_again:
if ((buffer_heads_over_limit is_highmem_idx(i)) ||
!zone_balanced(zone, testorder,
- balance_gap, end_zone)) {
- shrink_zone(zone, sc);
-
- reclaim_state-reclaimed_slab = 0;
- nr_slab =
Re: [PATCH v5 28/44] tty: Remove ldsem recursion support
On Mon, 2013-03-18 at 16:59 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 11, 2013 at 04:44:48PM -0400, Peter Hurley wrote: Read lock recursion is no longer required for ldisc references; remove mechanism. Signed-off-by: Peter Hurley pe...@hurleysoftware.com --- drivers/tty/tty_ldsem.c | 83 +-- include/linux/tty_ldisc.h | 2 -- 2 files changed, 8 insertions(+), 77 deletions(-) Wait, why did you add something 3 patches ago, only to remove it here? Why not just smush these patches together in the first place? From [PATCH v5 00/44] ldisc patchset... On Mon, 2013-03-11 at 16:44 -0400, Peter Hurley wrote: v5 changes: After completing an audit of the recursive use of ldisc references, I discovered the _blocking_ recursive acquisition of ldisc references was limited to line disciplines misusing the tty_perform_flush() function. With that now resolved in, 'tty: Fix recursive deadlock in tty_perform_flush()' the recursion design in ldsem has been removed. The recursion removal is in its own patch, 'tty: Remove ldsem recursion support' to ease review for those that have already reviewed the ldsem implementation. -- 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] usb: Make USB persist default configurable
Why can't you just revert this in userspace? Isn't that easier than doing a kernel patch and providing an option that we need to now maintain for pretty much forever? I could solve it in userspace, but that really feels like a hacky workaround and not a long term solution. It would mean that every new device starts with persist enabled and stays that way for a few milliseconds (maybe up to seconds if it's connected on boot), until userspace gets around to disable it again... opening the possibility for very weird race conditions and bugs with drivers/devices that don't work with persist. This default is a policy that really resides in the kernel, it has changed in the past, and since there is no definitive better choice for all cases I thought making it configurable is the right thing to do. -- 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] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
On Mon, Mar 18, 2013 at 06:28:53PM -0400, Jörn Engel wrote: It is possible for one thread to to take se_sess-sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd-cmd_kref before taking se_sess-sess_cmd_lock. This introduces kref_put_and_lock() and uses it in target_put_sess_cmd() to close the race window. We already have kref_put_mutex(), why not just call this kref_put_spinlock()? thanks, greg k-h -- 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 v5 28/44] tty: Remove ldsem recursion support
On Mon, Mar 18, 2013 at 08:01:01PM -0400, Peter Hurley wrote: On Mon, 2013-03-18 at 16:59 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 11, 2013 at 04:44:48PM -0400, Peter Hurley wrote: Read lock recursion is no longer required for ldisc references; remove mechanism. Signed-off-by: Peter Hurley pe...@hurleysoftware.com --- drivers/tty/tty_ldsem.c | 83 +-- include/linux/tty_ldisc.h | 2 -- 2 files changed, 8 insertions(+), 77 deletions(-) Wait, why did you add something 3 patches ago, only to remove it here? Why not just smush these patches together in the first place? From [PATCH v5 00/44] ldisc patchset... On Mon, 2013-03-11 at 16:44 -0400, Peter Hurley wrote: v5 changes: After completing an audit of the recursive use of ldisc references, I discovered the _blocking_ recursive acquisition of ldisc references was limited to line disciplines misusing the tty_perform_flush() function. With that now resolved in, 'tty: Fix recursive deadlock in tty_perform_flush()' the recursion design in ldsem has been removed. The recursion removal is in its own patch, 'tty: Remove ldsem recursion support' to ease review for those that have already reviewed the ldsem implementation. Ah, ok. Who reviewed the ldsem implementation? I didn't see any other acks on it, or did I miss them? thanks, greg k-h -- 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] usb: Make USB persist default configurable
On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote: Why can't you just revert this in userspace? Isn't that easier than doing a kernel patch and providing an option that we need to now maintain for pretty much forever? I could solve it in userspace, but that really feels like a hacky workaround and not a long term solution. It would mean that every new device starts with persist enabled and stays that way for a few milliseconds (maybe up to seconds if it's connected on boot), until userspace gets around to disable it again... opening the possibility for very weird race conditions and bugs with drivers/devices that don't work with persist. What drivers/devices don't work with persist? We need to know that now, otherwise all other distros and users have problems, right? This default is a policy that really resides in the kernel, it has changed in the past, and since there is no definitive better choice for all cases I thought making it configurable is the right thing to do. Too many options can be a bad thing. I think Alan made this a always on option, so I'd like to get his opinion on it. Alan? thanks, greg k-h -- 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 1/9] migrate: add migrate_entry_wait_huge()
On Mon, Mar 18, 2013 at 03:51:59PM +0100, Michal Hocko wrote:
On Thu 21-02-13 14:41:40, Naoya Horiguchi wrote:
[...]
diff --git v3.8.orig/mm/migrate.c v3.8/mm/migrate.c
index 2fd8b4a..7d84f4c 100644
--- v3.8.orig/mm/migrate.c
+++ v3.8/mm/migrate.c
@@ -236,6 +236,30 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t
*pmd,
pte_unmap_unlock(ptep, ptl);
}
+void migration_entry_wait_huge(struct mm_struct *mm, pmd_t *pmd,
+ unsigned long address)
+{
+ spinlock_t *ptl = pte_lockptr(mm, pmd);
+ pte_t pte;
+ swp_entry_t entry;
+ struct page *page;
+
+ spin_lock(ptl);
+ pte = huge_ptep_get((pte_t *)pmd);
+ if (!is_hugetlb_entry_migration(pte))
+ goto out;
+ entry = pte_to_swp_entry(pte);
+ page = migration_entry_to_page(entry);
+ if (!get_page_unless_zero(page))
+ goto out;
+ spin_unlock(ptl);
+ wait_on_page_locked(page);
+ put_page(page);
+ return;
+out:
+ spin_unlock(ptl);
+}
This duplicates a lot of code from migration_entry_wait. Can we just
teach the generic one to be HugePage aware instead?
All it takes is just opencoding pte_offset_map_lock and calling
huge_ptep_get ofr HugePage and pte_offset_map otherwise.
Yes, it's possible with some cleanup. I'll do this.
Thanks,
Naoya
--
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 2/9] migrate: make core migration code aware of hugepage
On Mon, Mar 18, 2013 at 04:33:00PM +0100, Michal Hocko wrote:
On Mon 18-03-13 16:22:24, Michal Hocko wrote:
On Thu 21-02-13 14:41:41, Naoya Horiguchi wrote:
[...]
diff --git v3.8.orig/include/linux/mempolicy.h
v3.8/include/linux/mempolicy.h
index 0d7df39..2e475b5 100644
--- v3.8.orig/include/linux/mempolicy.h
+++ v3.8/include/linux/mempolicy.h
@@ -173,7 +173,7 @@ extern int mpol_to_str(char *buffer, int maxlen,
struct mempolicy *pol);
/* Check if a vma is migratable */
static inline int vma_migratable(struct vm_area_struct *vma)
{
- if (vma-vm_flags (VM_IO | VM_HUGETLB | VM_PFNMAP))
+ if (vma-vm_flags (VM_IO | VM_PFNMAP))
return 0;
Is this safe? At least check_*_range don't seem to be hugetlb aware.
Ohh, they become in 5/9. Should that one be reordered then?
OK, I'll shift this change after 5/9 patch.
Naoya
--
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 5/9] migrate: enable migrate_pages() to migrate hugepage
On Mon, Mar 18, 2013 at 04:40:57PM +0100, Michal Hocko wrote:
On Thu 21-02-13 14:41:44, Naoya Horiguchi wrote:
This patch extends check_range() to handle vma with VM_HUGETLB set.
With this changes, we can migrate hugepage with migrate_pages(2).
Note that for larger hugepages (covered by pud entries, 1GB for
x86_64 for example), we simply skip it now.
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
---
include/linux/hugetlb.h | 6 --
mm/hugetlb.c| 10 ++
mm/mempolicy.c | 46 ++
3 files changed, 48 insertions(+), 14 deletions(-)
diff --git v3.8.orig/include/linux/hugetlb.h v3.8/include/linux/hugetlb.h
index 8f87115..eb33df5 100644
--- v3.8.orig/include/linux/hugetlb.h
+++ v3.8/include/linux/hugetlb.h
@@ -69,6 +69,7 @@ void hugetlb_unreserve_pages(struct inode *inode, long
offset, long freed);
int dequeue_hwpoisoned_huge_page(struct page *page);
void putback_active_hugepage(struct page *page);
void putback_active_hugepages(struct list_head *l);
+void migrate_hugepage_add(struct page *page, struct list_head *list);
void copy_huge_page(struct page *dst, struct page *src);
extern unsigned long hugepages_treat_as_movable;
@@ -88,8 +89,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm,
unsigned long address,
pmd_t *pmd, int write);
struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
pud_t *pud, int write);
-int pmd_huge(pmd_t pmd);
-int pud_huge(pud_t pmd);
+extern int pmd_huge(pmd_t pmd);
+extern int pud_huge(pud_t pmd);
extern is not needed here.
OK.
unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
unsigned long address, unsigned long end, pgprot_t newprot);
@@ -134,6 +135,7 @@ static inline int dequeue_hwpoisoned_huge_page(struct
page *page)
#define putback_active_hugepage(p) 0
#define putback_active_hugepages(l) 0
+#define migrate_hugepage_add(p, l) 0
static inline void copy_huge_page(struct page *dst, struct page *src)
{
}
diff --git v3.8.orig/mm/hugetlb.c v3.8/mm/hugetlb.c
index cb9d43b8..86ffcb7 100644
--- v3.8.orig/mm/hugetlb.c
+++ v3.8/mm/hugetlb.c
@@ -3202,3 +3202,13 @@ void putback_active_hugepages(struct list_head *l)
list_for_each_entry_safe(page, page2, l, lru)
putback_active_hugepage(page);
}
+
+void migrate_hugepage_add(struct page *page, struct list_head *list)
+{
+ VM_BUG_ON(!PageHuge(page));
+ get_page(page);
+ spin_lock(hugetlb_lock);
Why hugetlb_lock? Comment for this lock says that it protects
hugepage_freelists, nr_huge_pages, and free_huge_pages.
I think that this comment is out of date and hugepage_activelists,
which was introduced recently, should be protected because this
patchset adds is_hugepage_movable() which runs through the list.
So I'll update the comment in the next post.
+ list_move_tail(page-lru, list);
+ spin_unlock(hugetlb_lock);
+ return;
+}
diff --git v3.8.orig/mm/mempolicy.c v3.8/mm/mempolicy.c
index e2df1c1..8627135 100644
--- v3.8.orig/mm/mempolicy.c
+++ v3.8/mm/mempolicy.c
@@ -525,6 +525,27 @@ static int check_pte_range(struct vm_area_struct *vma,
pmd_t *pmd,
return addr != end;
}
+static void check_hugetlb_pmd_range(struct vm_area_struct *vma, pmd_t *pmd,
+ const nodemask_t *nodes, unsigned long flags,
+ void *private)
+{
+#ifdef CONFIG_HUGETLB_PAGE
+ int nid;
+ struct page *page;
+
+ spin_lock(vma-vm_mm-page_table_lock);
+ page = pte_page(huge_ptep_get((pte_t *)pmd));
+ spin_unlock(vma-vm_mm-page_table_lock);
I am a bit confused why page_table_lock is used here and why it doesn't
cover the page usage.
I expected this function to do the same for pmd as check_pte_range() does
for pte, but the above code didn't do it. I should've put spin_unlock
below migrate_hugepage_add(). Sorry for the confusion.
+ nid = page_to_nid(page);
+ if (node_isset(nid, *nodes) != !!(flags MPOL_MF_INVERT)
+((flags MPOL_MF_MOVE page_mapcount(page) == 1)
+ || flags MPOL_MF_MOVE_ALL))
+ migrate_hugepage_add(page, private);
+#else
+ BUG();
+#endif
+}
+
static inline int check_pmd_range(struct vm_area_struct *vma, pud_t *pud,
unsigned long addr, unsigned long end,
const nodemask_t *nodes, unsigned long flags,
@@ -536,6 +557,11 @@ static inline int check_pmd_range(struct
vm_area_struct *vma, pud_t *pud,
pmd = pmd_offset(pud, addr);
do {
next = pmd_addr_end(addr, end);
+ if (pmd_huge(*pmd) is_vm_hugetlb_page(vma)) {
Why an explicit check for is_vm_hugetlb_page here? Isn't pmd_huge()
sufficient?
I think we need both check here because if we use only pmd_huge(),
pmd for thp
Re: [PATCH 9/9] remove /proc/sys/vm/hugepages_treat_as_movable
On Mon, Mar 18, 2013 at 04:51:25PM +0100, Michal Hocko wrote: On Thu 21-02-13 14:41:48, Naoya Horiguchi wrote: Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. The sysctl is a part of user interface so you shouldn't remove it right away. What we can do is to make it noop and only WARN() that the interface will be removed later so that userspace can prepare for that. Yes, you're right. I'll replace the handler with noop. Thanks, Naoya -- 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 v5 28/44] tty: Remove ldsem recursion support
On Mon, 2013-03-18 at 17:05 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 18, 2013 at 08:01:01PM -0400, Peter Hurley wrote: On Mon, 2013-03-18 at 16:59 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 11, 2013 at 04:44:48PM -0400, Peter Hurley wrote: Read lock recursion is no longer required for ldisc references; remove mechanism. Signed-off-by: Peter Hurley pe...@hurleysoftware.com --- drivers/tty/tty_ldsem.c | 83 +-- include/linux/tty_ldisc.h | 2 -- 2 files changed, 8 insertions(+), 77 deletions(-) Wait, why did you add something 3 patches ago, only to remove it here? Why not just smush these patches together in the first place? From [PATCH v5 00/44] ldisc patchset... On Mon, 2013-03-11 at 16:44 -0400, Peter Hurley wrote: v5 changes: After completing an audit of the recursive use of ldisc references, I discovered the _blocking_ recursive acquisition of ldisc references was limited to line disciplines misusing the tty_perform_flush() function. With that now resolved in, 'tty: Fix recursive deadlock in tty_perform_flush()' the recursion design in ldsem has been removed. The recursion removal is in its own patch, 'tty: Remove ldsem recursion support' to ease review for those that have already reviewed the ldsem implementation. Ah, ok. Who reviewed the ldsem implementation? I didn't see any other acks on it, or did I miss them? Nobody ack'd it. What I meant by that was, if someone was working their way through it, it would suck to have the base implementation all different again, and much easier to review just the changes. -- 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] sysfs: use atomic_inc_unless_negative in sysfs_get_active
On Fri, Mar 08, 2013 at 04:07:27PM +0100, Maarten Lankhorst wrote:
It seems that sysfs has an interesting way of doing the same thing.
This removes the cpu_relax unfortunately, but if it's really needed,
it would be better to add this to include/linux/atomic.h to benefit
all atomic ops users.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Tejun wrote this code originally, so I'll defer to him as to if the
patch below is a valid cleanup or not.
Tejun?
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2fbdff6..7f968ed 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -165,21 +165,8 @@ struct sysfs_dirent *sysfs_get_active(struct
sysfs_dirent *sd)
if (unlikely(!sd))
return NULL;
- while (1) {
- int v, t;
-
- v = atomic_read(sd-s_active);
- if (unlikely(v 0))
- return NULL;
-
- t = atomic_cmpxchg(sd-s_active, v, v + 1);
- if (likely(t == v))
- break;
- if (t 0)
- return NULL;
-
- cpu_relax();
- }
+ if (!atomic_inc_unless_negative(sd-s_active))
+ return NULL;
if (likely(!ignore_lockdep(sd)))
rwsem_acquire_read(sd-dep_map, 0, 1, _RET_IP_);
--
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 0/2] Some cleanup in driver core
On Thu, Mar 07, 2013 at 10:22:44AM +0800, Wei Yang wrote: These two patches do some cleanup in the driver core. No they do not. I understand the need to fix code, but please, do so if it is broken. These patches don't help, and in fact, they hurt things. Next time, if you wish to send me patches like this, please get someone else at IBM, who is experienced, to ack them, before sending them on to me. greg k-h -- 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 1/2] driver core: remove device_add_attrs() in drivers/base/bus.c
On Thu, Mar 07, 2013 at 10:22:45AM +0800, Wei Yang wrote: Originally, we have two functions named device_add_attrs() in drivers/base/bus.c and drivers/base/core.c. This will cause some confusion when reading the code. Why? It's just static functions. And the one in drivers/base/bus.c do the same action as device_add_attributes() in drivers/base/core.c. That would be better to reuse this code. Possibly, yes, but you put the .h entry in the wrong place, thereby exposing a previously static function to the entire kernel, which is not good at all. Why did you do that? Are you now going to want to call that function from some driver? greg k-h -- 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/
linux-next: manual merge of the l2-mtd tree with Linus' tree
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/nand/nand_ids.c between commit 5bc7c33ca93a (mtd: nand:
reintroduce NAND_NO_READRDY as NAND_NEED_READRDY) from Linus' tree and
commit dc65c450 (mtd: add 4 Toshiba nand chips for the full-id
case) from the l2-mtd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/mtd/nand/nand_ids.c
index 9c61238,1c242cc..000
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@@ -10,163 -10,150 +10,153 @@@
*/
#include linux/module.h
#include linux/mtd/nand.h
- /*
- * Chip ID list
- *
- * Name. ID code, pagesize, chipsize in MegaByte, eraseblock size,
- * options
- *
- * Pagesize; 0, 256, 512
- * 0 get this information from the extended chip ID
- + 256 256 Byte page size
- * 512 512 Byte page size
- */
- struct nand_flash_dev nand_flash_ids[] = {
+ #include linux/sizes.h
+
+ #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
+ #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
+
+#define SP_OPTIONS NAND_NEED_READRDY
+#define SP_OPTIONS16 (SP_OPTIONS | NAND_BUSWIDTH_16)
+
- #ifdef CONFIG_MTD_NAND_MUSEUM_IDS
- {NAND 1MiB 5V 8-bit, 0x6e, 256, 1, 0x1000, SP_OPTIONS},
- {NAND 2MiB 5V 8-bit, 0x64, 256, 2, 0x1000, SP_OPTIONS},
- {NAND 4MiB 5V 8-bit, 0x6b, 512, 4, 0x2000, SP_OPTIONS},
- {NAND 1MiB 3,3V 8-bit,0xe8, 256, 1, 0x1000, SP_OPTIONS},
- {NAND 1MiB 3,3V 8-bit,0xec, 256, 1, 0x1000, SP_OPTIONS},
- {NAND 2MiB 3,3V 8-bit,0xea, 256, 2, 0x1000, SP_OPTIONS},
- {NAND 4MiB 3,3V 8-bit,0xd5, 512, 4, 0x2000, SP_OPTIONS},
- {NAND 4MiB 3,3V 8-bit,0xe3, 512, 4, 0x2000, SP_OPTIONS},
- {NAND 4MiB 3,3V 8-bit,0xe5, 512, 4, 0x2000, SP_OPTIONS},
- {NAND 8MiB 3,3V 8-bit,0xd6, 512, 8, 0x2000, SP_OPTIONS},
-
- {NAND 8MiB 1,8V 8-bit,0x39, 512, 8, 0x2000, SP_OPTIONS},
- {NAND 8MiB 3,3V 8-bit,0xe6, 512, 8, 0x2000, SP_OPTIONS},
- {NAND 8MiB 1,8V 16-bit, 0x49, 512, 8, 0x2000, SP_OPTIONS16},
- {NAND 8MiB 3,3V 16-bit, 0x59, 512, 8, 0x2000, SP_OPTIONS16},
- #endif
-
- {NAND 16MiB 1,8V 8-bit, 0x33, 512, 16, 0x4000, SP_OPTIONS},
- {NAND 16MiB 3,3V 8-bit, 0x73, 512, 16, 0x4000, SP_OPTIONS},
- {NAND 16MiB 1,8V 16-bit, 0x43, 512, 16, 0x4000, SP_OPTIONS16},
- {NAND 16MiB 3,3V 16-bit, 0x53, 512, 16, 0x4000, SP_OPTIONS16},
-
- {NAND 32MiB 1,8V 8-bit, 0x35, 512, 32, 0x4000, SP_OPTIONS},
- {NAND 32MiB 3,3V 8-bit, 0x75, 512, 32, 0x4000, SP_OPTIONS},
- {NAND 32MiB 1,8V 16-bit, 0x45, 512, 32, 0x4000, SP_OPTIONS16},
- {NAND 32MiB 3,3V 16-bit, 0x55, 512, 32, 0x4000, SP_OPTIONS16},
-
- {NAND 64MiB 1,8V 8-bit, 0x36, 512, 64, 0x4000, SP_OPTIONS},
- {NAND 64MiB 3,3V 8-bit, 0x76, 512, 64, 0x4000, SP_OPTIONS},
- {NAND 64MiB 1,8V 16-bit, 0x46, 512, 64, 0x4000, SP_OPTIONS16},
- {NAND 64MiB 3,3V 16-bit, 0x56, 512, 64, 0x4000, SP_OPTIONS16},
-
- {NAND 128MiB 1,8V 8-bit, 0x78, 512, 128, 0x4000, SP_OPTIONS},
- {NAND 128MiB 1,8V 8-bit, 0x39, 512, 128, 0x4000, SP_OPTIONS},
- {NAND 128MiB 3,3V 8-bit, 0x79, 512, 128, 0x4000, SP_OPTIONS},
- {NAND 128MiB 1,8V 16-bit, 0x72, 512, 128, 0x4000, SP_OPTIONS16},
- {NAND 128MiB 1,8V 16-bit, 0x49, 512, 128, 0x4000, SP_OPTIONS16},
- {NAND 128MiB 3,3V 16-bit, 0x74, 512, 128, 0x4000, SP_OPTIONS16},
- {NAND 128MiB 3,3V 16-bit, 0x59, 512, 128, 0x4000, SP_OPTIONS16},
-
- {NAND 256MiB 3,3V 8-bit, 0x71, 512, 256, 0x4000, SP_OPTIONS},
+ /*
+ * The chip ID list:
+ *name, device ID, page size, chip size in MiB, eraseblock size, options
+ *
+ * If page size and eraseblock size are 0, the sizes are taken from the
+ * extended chip ID.
+ */
+ struct nand_flash_dev nand_flash_ids[] = {
+ /*
+* Some incompatible NAND chips share device ID's and so must be
+* listed by full ID. We list them first so that we can easily identify
+* the most specific match.
+*/
+ {TC58NVG2S0F 4G 3.3V 8-bit,
+ { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 224},
+ {TC58NVG3S0F 8G 3.3V 8-bit,
+ { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
+ SZ_4K, SZ_1K, SZ_256K, 0, 8, 232},
+ {TC58NVG5D2 32G 3.3V 8-bit,
+ { .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
+ SZ_8K, SZ_4K, SZ_1M, 0, 8, 640},
+ {TC58NVG6D2 64G 3.3V 8-bit,
+ { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
+ SZ_8K, SZ_8K, SZ_2M, 0,
Re: [PATCH] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
On Mon, 18 March 2013 17:04:11 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 18, 2013 at 06:28:53PM -0400, Jörn Engel wrote: It is possible for one thread to to take se_sess-sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd-cmd_kref before taking se_sess-sess_cmd_lock. This introduces kref_put_and_lock() and uses it in target_put_sess_cmd() to close the race window. We already have kref_put_mutex(), why not just call this kref_put_spinlock()? Back when I originally wrote this patch, kref_put_mutex() didn't exist yet. So there is my evil predetermined plan to introduce random inconsistencies by being consistent with atomic_dec_and_lock() instead. If you think this matters I can rename the function and resend. Jörn -- Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success. -- Tom DeMarco -- 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 0/5] zcache: Support zero-filled pages more efficiently
On Fri, Mar 15, 2013 at 10:34:15AM +0800, Wanpeng Li wrote: Changelog: v2 - v3: * increment/decrement zcache_[eph|pers]_zpages for zero-filled pages, spotted by Dan * replace zero or zero page by zero_filled_page, spotted by Dan v1 - v2: * avoid changing tmem.[ch] entirely, spotted by Dan. * don't accumulate [eph|pers]pageframe and [eph|pers]zpages for zero-filled pages, spotted by Dan * cleanup TODO list * add Dan Acked-by. In the future, please make the subject: lines have staging: zcache: in them, so I don't have to edit them by hand. thanks, greg k-h -- 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] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
On Mon, Mar 18, 2013 at 06:56:57PM -0400, Jörn Engel wrote: On Mon, 18 March 2013 17:04:11 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 18, 2013 at 06:28:53PM -0400, Jörn Engel wrote: It is possible for one thread to to take se_sess-sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd-cmd_kref before taking se_sess-sess_cmd_lock. This introduces kref_put_and_lock() and uses it in target_put_sess_cmd() to close the race window. We already have kref_put_mutex(), why not just call this kref_put_spinlock()? Back when I originally wrote this patch, kref_put_mutex() didn't exist yet. So there is my evil predetermined plan to introduce random inconsistencies by being consistent with atomic_dec_and_lock() instead. Don't be evil, leave that up to the professionals :) If you think this matters I can rename the function and resend. Please do, it is good to name things correctly, when we have the chance. greg k-h -- 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: RFC (v2): Intel QST sensor driver
Hi Simon,
On Mon, Mar 18, 2013 at 09:20:53PM +, Simon J. Rowe wrote:
Hello,
I've made changes to my driver for the Intel Quiet System Technology
(QST) function that I posted at the end of last year and would again
appreciate feedback on it.
As before the git repo can be found here:
http://mose.dyndns.org/mei.git
Changes from v1
---
The module has been re-written to be data-driven rather than use
macros. Only v1 of the protocol is implemented but adding support for
v2 only requires three arrays and nine stub functions to be defined.
The code has been compiled and tested on 3.9 rc2.
The code has been fixed up after running checkpatch.pl.
Couple of problems I noticed when browsing through the code.
- Some functions return errors with return code 0.
if (ret = 0)
goto out;
...
out:
return ret;
For values of 0, the calling code will likely miss the error.
- In some cases, returned errors are replaced with another error
if (ret 0)
return -EIO;
You should return the original error.
- Try using something better than -EIO is possible. For example, you can use
-EINVAL for invalid parameters.
- Don't use strict_str functions. Use kstr functions instead (checkpatch should
tell you that, actually).
- Try using dev_ messages as much as possible (instead of pr_)
- Try allocating memory with devm_ functions. This way you can drop the matching
calls to kfree().
- I notice you use kmalloc() a lot. That is ok if you know that you'll
initialize all fields, but it is kind of risky. Better use kzalloc().
(if you start using devm_kzalloc, the issue becomes mostly irrelevant,
as there is no devm_kmalloc).
I've added documents that explain the QST protocol and also the design
of the driver.
For my part I like the architecture of your driver. Wonder how difficult
it would be to implement the functionality supported by the in-kernel driver
(eg watchdog) with your infrastructure.
Overall it would be great if you and Tomas could get together and come up
with a unified implementation.
Thanks,
Guenter
Unchanged from v1
-
The driver still uses my MEI implementation. I've taken a look at the
Intel-written driver in 3.9 and it still has no obvious way to be used
by another driver, in the same directory or otherwise. The lack of
documentation may mean I've overlooked something obvious.
The following patch is still required to prevent libsensors from
ignoring the hwmon directory
diff -ur lm_sensors-3.3.1.org/lib/sysfs.c lm_sensors-3.3.1/lib/sysfs.c
--- lm_sensors-3.3.1.org/lib/sysfs.c 2011-03-04 20:37:43.0 +
+++ lm_sensors-3.3.1/lib/sysfs.c2012-11-14 21:48:52.144860375 +
@@ -701,6 +701,12 @@
/* As of kernel 2.6.32, the hid device names don't
look good */
entry.chip.bus.nr = bus;
entry.chip.addr = id;
+ } else
+ if (subsys !strcmp(subsys, intel-mei)
+ sscanf(dev_name, mei%d:%d, bus, fn) == 2) {
+ entry.chip.bus.type = SENSORS_BUS_TYPE_PCI;
+ entry.chip.bus.nr = bus;
+ entry.chip.addr = fn;
} else {
/* Ignore unknown device */
err = 0;
PWM is still unimplemented.
--
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 1/3] rbtree_test: use pr_info for module prefix in messages
On Mon, 2013-03-18 at 16:47 -0700, Davidlohr Bueso wrote: On Mon, 2013-03-18 at 16:44 -0700, Joe Perches wrote: On Mon, 2013-03-18 at 16:20 -0700, Davidlohr Bueso wrote: This provides nicer message output. Since it seems more appropriate for the nature of this module, also use KERN_INFO instead of other levels. [] diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c [] @@ -153,7 +156,7 @@ static int rbtree_test_init(void) int i, j; cycles_t time1, time2, time; - printk(KERN_ALERT rbtree testing); + pr_info(rbtree testing); prandom_seed_state(rnd, 3141592653589793238ULL); init(); @@ -171,7 +174,7 @@ static int rbtree_test_init(void) time = time2 - time1; time = div_u64(time, PERF_LOOPS); - printk( - %llu cycles\n, (unsigned long long)time); + pr_info( - %llu cycles\n, (unsigned long long)time); You change the output here by more than just adding a prefix. The first printk didn't have a newline. The old code would print: rbtree testing - foo cycles The new code prints: rbtree_test: rbtree testing rbtree_test: - foo cycles Ah, I see. This is actually the first time I'm using pr_* calls. I actually don't mind the new format, it looked ok, but if others don't agree, I can always resend it. Your choice. I don't prefer one over the other. I do prefer you add an explicit newline to the first format though instead of relying on the implicit newline the printk subsystem will emit during the next pr_level call. cheers, Joe -- 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] sysfs: use atomic_inc_unless_negative in sysfs_get_active
On Mon, Mar 18, 2013 at 05:14:18PM -0700, Greg KH wrote:
On Fri, Mar 08, 2013 at 04:07:27PM +0100, Maarten Lankhorst wrote:
It seems that sysfs has an interesting way of doing the same thing.
This removes the cpu_relax unfortunately, but if it's really needed,
it would be better to add this to include/linux/atomic.h to benefit
all atomic ops users.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Tejun wrote this code originally, so I'll defer to him as to if the
patch below is a valid cleanup or not.
Yeah, I think that code predates atomic_inc_unless_negative().
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2fbdff6..7f968ed 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -165,21 +165,8 @@ struct sysfs_dirent *sysfs_get_active(struct
sysfs_dirent *sd)
if (unlikely(!sd))
return NULL;
- while (1) {
- int v, t;
-
- v = atomic_read(sd-s_active);
- if (unlikely(v 0))
- return NULL;
-
- t = atomic_cmpxchg(sd-s_active, v, v + 1);
- if (likely(t == v))
- break;
- if (t 0)
- return NULL;
-
- cpu_relax();
- }
+ if (!atomic_inc_unless_negative(sd-s_active))
+ return NULL;
Looks good to me.
Acked-by: Tejun Heo t...@kernel.org
Thanks.
--
tejun
--
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] x86, kdump: Set crashkernel_low automatically
On 03/18/2013 04:26 PM, Yinghai Lu wrote: now only have: swiotlb overflow buffer v_overflow_buffer = alloc_bootmem_low_pages_nopanic( PAGE_ALIGN(io_tlb_overflow)); and /* * When the IOMMU overflows we return a fallback buffer. This sets the size. */ static unsigned long io_tlb_overflow = 32*1024; so it is 32K, and I round it to 8M. So put that into prose, understandable by someone who hasn't followed this discussion (say, five years from now), and make that part of the commit. -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
On Mon, 18 March 2013 17:27:42 -0700, Greg Kroah-Hartman wrote:
On Mon, Mar 18, 2013 at 06:56:57PM -0400, Jörn Engel wrote:
Back when I originally wrote this patch, kref_put_mutex() didn't exist
yet. So there is my evil predetermined plan to introduce random
inconsistencies by being consistent with atomic_dec_and_lock()
instead.
Don't be evil, leave that up to the professionals :)
I wouldn't dare question your authority in such matters. :-P
If you think this matters I can rename the function and resend.
Please do, it is good to name things correctly, when we have the chance.
Fair enough.
Jörn
--
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c
It is possible for one thread to to take se_sess-sess_cmd_lock in
core_tmr_abort_task() before taking a reference count on
se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops
se_cmd-cmd_kref before taking se_sess-sess_cmd_lock.
This introduces kref_put_and_lock() and uses it in
target_put_sess_cmd() to close the race window.
Signed-off-by: Joern Engel jo...@logfs.org
---
drivers/target/target_core_transport.c | 17 +++--
include/linux/kref.h | 26 ++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 04ec9cb..b98c158 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2207,21 +2207,19 @@ static void target_release_cmd_kref(struct kref *kref)
{
struct se_cmd *se_cmd = container_of(kref, struct se_cmd, cmd_kref);
struct se_session *se_sess = se_cmd-se_sess;
- unsigned long flags;
- spin_lock_irqsave(se_sess-sess_cmd_lock, flags);
if (list_empty(se_cmd-se_cmd_list)) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
return;
}
if (se_sess-sess_tearing_down se_cmd-cmd_wait_set) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
complete(se_cmd-cmd_wait_comp);
return;
}
list_del(se_cmd-se_cmd_list);
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
}
@@ -2232,7 +2230,14 @@ static void target_release_cmd_kref(struct kref *kref)
*/
int target_put_sess_cmd(struct se_session *se_sess, struct se_cmd *se_cmd)
{
- return kref_put(se_cmd-cmd_kref, target_release_cmd_kref);
+ unsigned long flags;
+ int ret;
+
+ local_irq_save(flags);
+ ret = kref_put_spinlock(se_cmd-cmd_kref, target_release_cmd_kref,
+ se_sess-sess_cmd_lock);
+ local_irq_restore(flags);
+ return ret;
}
EXPORT_SYMBOL(target_put_sess_cmd);
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 4972e6e..c40eaf6 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -19,6 +19,7 @@
#include linux/atomic.h
#include linux/kernel.h
#include linux/mutex.h
+#include linux/spinlock_types.h
struct kref {
atomic_t refcount;
@@ -95,6 +96,31 @@ static inline int kref_put(struct kref *kref, void
(*release)(struct kref *kref)
return kref_sub(kref, 1, release);
}
+/**
+ * kref_put_and_lock - decrement refcount for object.
+ * @kref: object.
+ * @release: pointer to the function that will clean up the object when the
+ * last reference to the object is released.
+ * This pointer is required, and it is not acceptable to pass kfree
+ * in as this function.
+ * @lock: lock to take in release case
+ *
+ * Behaves identical to kref_put with one exception. If the reference count
+ * drops to zero, the lock will be taken atomically wrt dropping the reference
+ * count.
+ */
+static inline int kref_put_spinlock(struct kref *kref,
+ void (*release)(struct kref *kref),
+ spinlock_t *lock)
+{
+ WARN_ON(release == NULL);
+ if (atomic_dec_and_lock(kref-refcount, lock)) {
+ release(kref);
+ return 1;
+ }
+ return 0;
+}
+
static inline int kref_put_mutex(struct kref *kref,
void (*release)(struct kref *kref),
struct mutex *lock)
--
1.7.10.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/
Re: [PATCH 2/4] Input: cyapa - Firmware update via request firmware
On Sat, Mar 16, 2013 at 1:00 PM, Henrik Rydberg rydb...@euromail.se wrote: Userspace can initiate the firmware update procedure by copying cyapa.bin to /lib/firmware, and then writing anything to the device sysfs attribute: /sys/bus/i2c/devices/7-0067/update_fw Why do you need to trigger this from userland via sysfs? It's a confluence of factors that drives the decision trigger from userland. - As a part of the cold-boot probe steps, the trackpad's bootloader will load an operational firmware from its flash memory. In the average case, the trackpad driver does not need to update the firmware because it's current. (the non-average cases are cases where on device firmware is corrupted or out of date) - The cypress firmware payloads we are working with here do not contain an indication of firmware version in the payload itself, so the driver can't tell at probe time whether what it would get if it request_firmware is newer, older, or the same version as what's already loaded on the trackpad. - On a 400kHz i2c bus, it takes 13 seconds to send the 31K payload to the device and to wait for it to jump into the operational mode firmware. This is too long to block probe every time. - Because it takes so long to do a firmware update, our user space would like to put up a warning message anyhow to tell the user that the touchpad is being updated, and not to disturb the system. + if (sysfs_create_group(client-dev.kobj, cyapa_sysfs_group)) + dev_warn(dev, error creating sysfs entries.\n); + Would it not be neat to invoke the firmware update automatically instead? The one situation where I could see an automatic firmware update being useful would be cases where the driver, during probe, discovered that the trackpad is in Bootloader mode because no valid firmware was found (a case of corruption of some kind due to the system powering down during a previous fw update, or example). In that case, the driver can request firmware and update it without user space having to trigger it later. Another driver in input does it the same way. atmel_mxt_ts.c, which our team is actively working on as well, also has an update_fw sysfs for a lot of the same reasons. Thanks, -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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] drivers: ptp: Use memdup_user function
Used memdup_user function instead of kmalloc followed by copy_from_user.
Also, handled return error using IS_ERR and PTR_ERR.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu gheorghiuan...@gmail.com
---
drivers/ptp/ptp_chardev.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 34a0c60..bd7a2ab 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -94,14 +94,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
break;
case PTP_SYS_OFFSET:
- sysoff = kmalloc(sizeof(*sysoff), GFP_KERNEL);
- if (!sysoff) {
- err = -ENOMEM;
- break;
- }
- if (copy_from_user(sysoff, (void __user *)arg,
- sizeof(*sysoff))) {
- err = -EFAULT;
+ sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
+ if (IS_ERR(sysoff)) {
+ err = PTR_ERR(sysoff);
break;
}
if (sysoff-n_samples PTP_MAX_SAMPLES) {
--
1.7.9.5
--
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 v5 1/3] gpio: gpio-generic: Add 16 and 32 bit big endian byte order support
On Fri, Mar 15, 2013 at 02:45:38PM +0100, Andreas Larsson wrote: There is no general support for 64-bit big endian accesses, so that is left unsupported. Signed-off-by: Andreas Larsson andr...@gaisler.com This looks perfect, thanks a lot! Acked-by: Anton Vorontsov an...@enomsg.org -- 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] memstick: r592: make r592_pm_ops static
r592_pm_ops is not exported. Also, CONFIG_PM_SLEEP is used to
remove unnecessary ifdefs.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Maxim Levitsky maximlevit...@gmail.com
---
drivers/memstick/host/r592.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
index a7c5b31..9718661 100644
--- a/drivers/memstick/host/r592.c
+++ b/drivers/memstick/host/r592.c
@@ -847,7 +847,7 @@ static void r592_remove(struct pci_dev *pdev)
dev-dummy_dma_page_physical_address);
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int r592_suspend(struct device *core_dev)
{
struct pci_dev *pdev = to_pci_dev(core_dev);
@@ -870,10 +870,10 @@ static int r592_resume(struct device *core_dev)
r592_update_card_detect(dev);
return 0;
}
-
-SIMPLE_DEV_PM_OPS(r592_pm_ops, r592_suspend, r592_resume);
#endif
+static SIMPLE_DEV_PM_OPS(r592_pm_ops, r592_suspend, r592_resume);
+
MODULE_DEVICE_TABLE(pci, r592_pci_id_tbl);
static struct pci_driver r852_pci_driver = {
@@ -881,9 +881,7 @@ static struct pci_driver r852_pci_driver = {
.id_table = r592_pci_id_tbl,
.probe = r592_probe,
.remove = r592_remove,
-#ifdef CONFIG_PM
.driver.pm = r592_pm_ops,
-#endif
};
static __init int r592_module_init(void)
--
1.7.2.5
--
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: [ 00/40] 3.0.70-stable review
On Mon, Mar 18, 2013 at 3:10 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: This is the start of the stable review cycle for the 3.0.70 release. There are 40 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 20 21:10:06 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.70-rc1.gz and the diffstat can be found below. thanks, greg k-h - I am seeing the following warning right after resume: [ 338.872618] [ cut here ] [ 338.872623] WARNING: at kernel/power/suspend_test.c:53 suspend_test_finish+0x86/0x90() [ 338.872625] Hardware name: HP EliteBook 6930p [ 338.872626] Component: resume devices, time: 10068 [ 338.872627] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc bluetooth radeon snd_hda_codec_analog snd_hda_intel snd_hda_codec ttm snd_hwdep snd_pcm snd_seq_midi snd_rawmidi binfmt_misc drm_kms_helper snd_seq_midi_event drm snd_seq snd_timer snd_seq_device snd pata_pcmcia joydev tpm_infineon dm_multipath soundcore psmouse snd_page_alloc pcmcia hp_accel ppdev serio_raw i2c_algo_bit lis3lv02d hp_wmi sparse_keymap parport_pc yenta_socket pcmcia_rsrc pcmcia_core input_polldev video mac_hid wmi tpm_tis lp parport firewire_ohci firewire_core sdhci_pci crc_itu_t sdhci e1000e [last unloaded: kvm] [ 338.872662] Pid: 2656, comm: bash Not tainted 3.0.70-rc1+ #15 [ 338.872664] Call Trace: [ 338.872667] [8105ef1f] warn_slowpath_common+0x7f/0xc0 [ 338.872670] [8105f016] warn_slowpath_fmt+0x46/0x50 [ 338.872672] [810a1b16] suspend_test_finish+0x86/0x90 [ 338.872675] [810a16f4] suspend_devices_and_enter+0xd4/0x2e0 [ 338.872677] [810a1a1d] enter_state+0x11d/0x150 [ 338.872679] [810a0e67] state_store+0xb7/0xf0 [ 338.872682] [812d531f] kobj_attr_store+0xf/0x30 [ 338.872685] [811ce64f] sysfs_write_file+0xef/0x170 [ 338.872688] [8115e2a3] vfs_write+0xb3/0x180 [ 338.872691] [8115e5ca] sys_write+0x4a/0x90 [ 338.872694] [81604b42] system_call_fastpath+0x16/0x1b [ 338.872696] ---[ end trace 9c87f459a9254076 ]--- [ 338.872805] PM: Finishing wakeup. [ 338.872806] Restarting tasks ... done. [ 338.886692] video LNXVIDEO:00: Restoring backlight state -- Shuah -- 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] zero-filled pages awareness
On Fri, Mar 15, 2013 at 10:34:17AM +0800, Wanpeng Li wrote: Compression of zero-filled pages can unneccessarily cause internal fragmentation, and thus waste memory. This special case can be optimized. This patch captures zero-filled pages, and marks their corresponding zcache backing page entry as zero-filled. Whenever such zero-filled page is retrieved, we fill the page frame with zero. Acked-by: Dan Magenheimer dan.magenhei...@oracle.com Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com This patch applies with a bunch of fuzz, meaning it wasn't made against the latest tree, which worries me. Care to redo it, and the rest of the series, and resend it? thanks, greg k-h -- 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: [ 00/48] 3.4.37-stable review
On Mon, Mar 18, 2013 at 3:08 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: This is the start of the stable review cycle for the 3.4.37 release. There are 48 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 20 21:07:59 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.37-rc1.gz and the diffstat can be found below. thanks, greg k-h I am seeing the following warning after suspend and resume: [ 665.841331] Component: resume devices, time: 10628 [ 665.841335] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm bnep rfcomm bluetooth arc4 iwlwifi radeon snd_hda_codec_analog snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm snd_seq_midi binfmt_misc snd_rawmidi snd_seq_midi_event snd_seq ttm pata_pcmcia snd_timer cfg80211 drm_kms_helper drm snd_seq_device tpm_infineon pcmcia psmouse snd coretemp hp_wmi soundcore joydev sparse_keymap snd_page_alloc yenta_socket hp_accel pcmcia_rsrc dm_multipath video microcode serio_raw mac_hid lis3lv02d input_polldev ppdev tpm_tis i2c_algo_bit pcmcia_core wmi parport_pc lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci e1000e [ 665.841446] Pid: 2686, comm: bash Not tainted 3.4.37-rc1+ #13 [ 665.841450] Call Trace: [ 665.841463] [8105136f] warn_slowpath_common+0x7f/0xc0 [ 665.841471] [81051466] warn_slowpath_fmt+0x46/0x50 [ 665.841478] [81097086] suspend_test_finish+0x86/0x90 [ 665.841484] [81096c2e] suspend_devices_and_enter+0x16e/0x330 [ 665.841491] [81096f7f] pm_suspend+0x18f/0x1f0 [ 665.841500] [81095f97] state_store+0xb7/0xf0 [ 665.841508] [81309a7f] kobj_attr_store+0xf/0x30 [ 665.841518] [811e230f] sysfs_write_file+0xef/0x170 [ 665.841528] [81173b43] vfs_write+0xb3/0x180 [ 665.841534] [81173e6a] sys_write+0x4a/0x90 [ 665.841543] [81664329] system_call_fastpath+0x16/0x1b [ 665.841548] ---[ end trace bf9a1fe573180bcc ]--- [ 665.841843] PM: Finishing wakeup. [ 665.841848] Restarting tasks ... done. Same thing on 3.8.4-rc1. -- Shuah -- 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: [ 00/75] 3.8.4-stable review
On Mon, Mar 18, 2013 at 3:06 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: This is the start of the stable review cycle for the 3.8.4 release. There are 75 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 20 21:04:55 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.4-rc1.gz and the diffstat can be found below. thanks, greg k-h Here is the warn from 3.8.4-rc1 [ 700.009112] Component: resume devices, time: 10004 [ 700.009204] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc bnep rfcomm bluetooth arc4 iwldvm snd_hda_codec_analog radeon snd_hda_intel mac80211 coretemp snd_hda_codec kvm_intel kvm snd_hwdep binfmt_misc snd_pcm snd_seq_midi iwlwifi snd_rawmidi ttm snd_seq_midi_event cfg80211 drm_kms_helper pata_pcmcia snd_seq tpm_infineon drm psmouse snd_timer joydev pcmcia snd_seq_device snd yenta_socket tpm_tis microcode pcmcia_rsrc pcmcia_core ppdev dm_multipath i2c_algo_bit video hp_wmi mac_hid sparse_keymap serio_raw soundcore snd_page_alloc lpc_ich wmi hp_accel lis3lv02d input_polldev parport_pc lp parport firewire_ohci sdhci_pci sdhci firewire_core crc_itu_t e1000e [ 700.009212] Pid: 2637, comm: bash Not tainted 3.8.4-rc1+ #8 [ 700.009213] Call Trace: [ 700.009225] [8105821f] warn_slowpath_common+0x7f/0xc0 [ 700.009231] [81058316] warn_slowpath_fmt+0x46/0x50 [ 700.009237] [810a3196] suspend_test_finish+0x86/0x90 [ 700.009243] [810a2d3e] suspend_devices_and_enter+0x16e/0x330 [ 700.009248] [810a308f] pm_suspend+0x18f/0x1f0 [ 700.009254] [810a208e] state_store+0x8e/0xf0 [ 700.009261] [8133218f] kobj_attr_store+0xf/0x30 [ 700.009268] [811fae0f] sysfs_write_file+0xef/0x170 [ 700.009274] [811879e3] vfs_write+0xb3/0x180 [ 700.009278] [81187d22] sys_write+0x52/0xa0 [ 700.009284] [811a4810] ? __close_fd+0x90/0xc0 [ 700.009291] [816b4bd9] system_call_fastpath+0x16/0x1b [ 700.009294] ---[ end trace f7ca5ea4ac88428b ]--- [ 700.009728] PM: Finishing wakeup. [ 700.009731] Restarting tasks ... done. -- Shuah -- 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: [ 00/75] 3.8.4-stable review
On Mon, Mar 18, 2013 at 06:51:37PM -0600, Shuah Khan wrote: On Mon, Mar 18, 2013 at 3:06 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: This is the start of the stable review cycle for the 3.8.4 release. There are 75 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 20 21:04:55 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.4-rc1.gz and the diffstat can be found below. thanks, greg k-h Here is the warn from 3.8.4-rc1 [ 700.009112] Component: resume devices, time: 10004 [ 700.009204] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc bnep rfcomm bluetooth arc4 iwldvm snd_hda_codec_analog radeon snd_hda_intel mac80211 coretemp snd_hda_codec kvm_intel kvm snd_hwdep binfmt_misc snd_pcm snd_seq_midi iwlwifi snd_rawmidi ttm snd_seq_midi_event cfg80211 drm_kms_helper pata_pcmcia snd_seq tpm_infineon drm psmouse snd_timer joydev pcmcia snd_seq_device snd yenta_socket tpm_tis microcode pcmcia_rsrc pcmcia_core ppdev dm_multipath i2c_algo_bit video hp_wmi mac_hid sparse_keymap serio_raw soundcore snd_page_alloc lpc_ich wmi hp_accel lis3lv02d input_polldev parport_pc lp parport firewire_ohci sdhci_pci sdhci firewire_core crc_itu_t e1000e [ 700.009212] Pid: 2637, comm: bash Not tainted 3.8.4-rc1+ #8 Do you get this same warning on 3.9-rc3? I thought I got all of the needed fixes for this warning, what am I missing here? thanks, greg k-h -- 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: [ 04/21] target/pscsi: Fix page increment
On Mon, Mar 18, 2013 at 11:30:47PM +, Ben Hutchings wrote:
On Mon, 2013-03-18 at 14:00 -0700, Nicholas A. Bellinger wrote:
On Mon, 2013-03-18 at 13:35 +0800, Asias He wrote:
On Sat, Mar 16, 2013 at 02:10:22AM +, Ben Hutchings wrote:
On Tue, 2013-03-12 at 15:44 -0700, Greg Kroah-Hartman wrote:
3.0-stable review patch. If anyone has any objections, please let me
know.
--
From: Asias He as...@redhat.com
commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.
The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong
page
address if the 'while (len 0 data_len 0) { ... }' loop is
executed more than one once.
Signed-off-by: Asias He as...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/target/target_core_pscsi.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1210,7 +1210,6 @@ static int __pscsi_map_task_SG(
bio = NULL;
}
- page++;
len -= bytes;
data_len -= bytes;
off = 0;
So in case a fragment crosses a page boundary, we wrap around to the
beginning of the same page? That doesn't look right.
If the fragment crosses a page boundary, what is the correct page
for it?
Nicholas, can we assume sg-length + sg-offset should be less than
PAGE_SIZE here?
sg-length + sg-offset can be less than or equal to PAGE_SIZE here.
For everything other than tcm_loop + tcm_vhost using externally
allocated SGLs, we can expect fragments to never cross the page
boundary.
For tcm_loop + tcm_vhost, there are a few special cases with control CDB
paylaods (usually going through scsi-generic) where we can have a non
zero sg-offset, but at least in the cases I've seen this is still not
using SGL elements that exceed PAGE_SIZE.
So, I think this logic is OK for SGLs that cross page boundries, given
that it's done outside of the inner loop where *page is set during each
for_each_sg().
The page is set using sg_page() in the outer loop and was then
incremented in the inner loop.
for_each_sg(sgl, sg, sgl_nents, i) {
page = sg_page(sg);
off = sg-offset;
len = sg-length;
while (len 0 data_len 0) {
bytes = min_t(unsigned int, len, PAGE_SIZE - off);
bytes = min(bytes, data_len);
...
/* page++; */
len -= bytes;
data_len -= bytes;
off = 0;
}
}
The inner loop is apparently meant to iterate over pages of a segment,
but is now just wrapping around a single page.
Yes, but we never loop more than once in the inner loop.
So, how about
1) fail on sg-offset + sg-length PAGE_SIZE (we can not find a
proper page address in this case)
2) remove the inner while loop, run the code was in the loop only once.
The case where this logic is broken, and that the 'page
++' was addressing is when sg-length PAGE_SIZE.
That is a sufficient but not a necessary condition for the increment.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
--
Asias
--
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: [ 00/48] 3.4.37-stable review
On Mon, 18 Mar 2013, Shuah Khan wrote: I am seeing the following warning after suspend and resume: [ 665.841331] Component: resume devices, time: 10628 [snip] [ 665.841446] Pid: 2686, comm: bash Not tainted 3.4.37-rc1+ #13 [ 665.841450] Call Trace: [ 665.841463] [8105136f] warn_slowpath_common+0x7f/0xc0 [ 665.841471] [81051466] warn_slowpath_fmt+0x46/0x50 [ 665.841478] [81097086] suspend_test_finish+0x86/0x90 [ 665.841484] [81096c2e] suspend_devices_and_enter+0x16e/0x330 [ 665.841491] [81096f7f] pm_suspend+0x18f/0x1f0 It is coming from kernel/power/suspend_test.c:53 - /* Warning on suspend means the RTC alarm period needs to be * larger -- the system was sooo slooo to suspend that the * alarm (should have) fired before the system went to sleep! * * Warning on either suspend or resume also means the system * has some performance issues. The stack dump of a WARN_ON * is more likely to get the right attention than a printk... */ WARN(msec (TEST_SUSPEND_SECONDS * 1000), Component: %s, time: %u\n, label, msec); That just means your system is slow to suspend/resume. I've seen the same many times on my older machines - you can likely ignore it. --Parag -- 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 v3] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race
And because I'm lame and stupid, here's v3.
It is possible for one thread to to take se_sess-sess_cmd_lock in
core_tmr_abort_task() before taking a reference count on
se_cmd-cmd_kref, while another thread in target_put_sess_cmd() drops
se_cmd-cmd_kref before taking se_sess-sess_cmd_lock.
This introduces kref_put_and_lock() and uses it in
target_put_sess_cmd() to close the race window.
Signed-off-by: Joern Engel jo...@logfs.org
---
drivers/target/target_core_transport.c | 17 +++--
include/linux/kref.h | 26 ++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 04ec9cb..b98c158 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2207,21 +2207,19 @@ static void target_release_cmd_kref(struct kref *kref)
{
struct se_cmd *se_cmd = container_of(kref, struct se_cmd, cmd_kref);
struct se_session *se_sess = se_cmd-se_sess;
- unsigned long flags;
- spin_lock_irqsave(se_sess-sess_cmd_lock, flags);
if (list_empty(se_cmd-se_cmd_list)) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
return;
}
if (se_sess-sess_tearing_down se_cmd-cmd_wait_set) {
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
complete(se_cmd-cmd_wait_comp);
return;
}
list_del(se_cmd-se_cmd_list);
- spin_unlock_irqrestore(se_sess-sess_cmd_lock, flags);
+ spin_unlock(se_sess-sess_cmd_lock);
se_cmd-se_tfo-release_cmd(se_cmd);
}
@@ -2232,7 +2230,14 @@ static void target_release_cmd_kref(struct kref *kref)
*/
int target_put_sess_cmd(struct se_session *se_sess, struct se_cmd *se_cmd)
{
- return kref_put(se_cmd-cmd_kref, target_release_cmd_kref);
+ unsigned long flags;
+ int ret;
+
+ local_irq_save(flags);
+ ret = kref_put_spinlock(se_cmd-cmd_kref, target_release_cmd_kref,
+ se_sess-sess_cmd_lock);
+ local_irq_restore(flags);
+ return ret;
}
EXPORT_SYMBOL(target_put_sess_cmd);
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 4972e6e..1f26a86 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -19,6 +19,7 @@
#include linux/atomic.h
#include linux/kernel.h
#include linux/mutex.h
+#include linux/spinlock.h
struct kref {
atomic_t refcount;
@@ -95,6 +96,31 @@ static inline int kref_put(struct kref *kref, void
(*release)(struct kref *kref)
return kref_sub(kref, 1, release);
}
+/**
+ * kref_put_and_lock - decrement refcount for object.
+ * @kref: object.
+ * @release: pointer to the function that will clean up the object when the
+ * last reference to the object is released.
+ * This pointer is required, and it is not acceptable to pass kfree
+ * in as this function.
+ * @lock: lock to take in release case
+ *
+ * Behaves identical to kref_put with one exception. If the reference count
+ * drops to zero, the lock will be taken atomically wrt dropping the reference
+ * count.
+ */
+static inline int kref_put_spinlock(struct kref *kref,
+ void (*release)(struct kref *kref),
+ spinlock_t *lock)
+{
+ WARN_ON(release == NULL);
+ if (atomic_dec_and_lock(kref-refcount, lock)) {
+ release(kref);
+ return 1;
+ }
+ return 0;
+}
+
static inline int kref_put_mutex(struct kref *kref,
void (*release)(struct kref *kref),
struct mutex *lock)
--
1.7.10.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/
Re: [PATCH v5 26/44] tty: Add read-recursive, writer-prioritized rw semaphore
On Mon, 2013-03-18 at 16:58 -0700, Greg Kroah-Hartman wrote: On Mon, Mar 11, 2013 at 04:44:46PM -0400, Peter Hurley wrote: The semantics of a rw semaphore are almost ideally suited for tty line discipline lifetime management; multiple active threads obtain references (read locks) while performing i/o to prevent the loss or change of the current line discipline (write lock). Unfortunately, the existing rw_semaphore is ill-suited in other ways; 1) obtaining a reference can be recursive, ie., a reference holder may attempt to obtain another reference. Recursive read locks are not supported by rwsem. Why does a ldisc need to obtain this recursively? You already discovered it doesn't (but it used to be required). BTW, it's only because I had a real lock with lockdep support, that this recursive usage which deadlocks was even discoverable. 2) TIOCSETD ioctl (change line discipline) expects to return an error if the line discipline cannot be exclusively locked within 5 secs. Lock wait timeouts are not supported by rwsem. Don't we have some other lock that can timeout? Not that behaves like a r/w semaphore. 3) A tty hangup is expected to halt and scrap pending i/o, so exclusive locking must be prioritized without precluding existing reference holders from obtaining recursive read locks. Writer priority is not supported by rwsem. But how bad is it really if we have to wait a bit for that write lock to get through all of the existing readers? Either way, we are supposed to be dropping i/o, so it shouldn't be a big deal, right? The rwsem behavior is in the process of changing. Write lock stealing has already been added and refinements there will likely allow some readers in front of writers. With slow serial i/o, I'd rather have hangups occur promptly than let a bunch more i/o through. Add ld_semaphore which implements these requirements in a semantically and operationally similar way to rw_semaphore. I _really_ don't want to add a new lock to the kernel, especially one that is only used by one driver. You are going to have to convince the current lock authors that this really is needed, before I can take it, sorry. That's fine. I can understand the reluctance to take on a new lock [although you might be interested to read my analysis of rwsem here https://lkml.org/lkml/2013/3/11/533 which outlines an existing flaw]. That said, part of the reason why the current ldisc implementation is broken is the lack of appropriate locks. As I recently explained (actually in this patchset's thread), a lack of existing options has spawned a DIY approach without higher-order locks that is rarely correct, but which goes largely unnoticed exactly because it's not a new lock. A brief review of the hangs, races, and deadlocks fixed by this patchset should be convincing enough of that fact. In my opinion, this is the overriding concern. The two main problems with a one-size-fits-all lock policy is that, 1) lock experts can't realistically foresee the consequences of policy changes without already being experts in the subsystems in which that lock is used. Even domain experts may miss potential consequences, and 2) domain experts typically wouldn't even consider writing a new lock. So they make do with atomic bit states, spinlocks, reference counts, mutexes, and waitqueues, making a mostly-functional, higher-order lock. From whom would you like me to get an ack for this? What is wrong with the existing ldisc code that the creation of this lock is needed? Is our current code that broken? Yes. Even just the acquistion of the ldisc reference is wrong [the analysis is in the patch 21 changelog]. If you'd like, I can send you 6 or so short user test programs that hang, crash, or deadlock inside 60 seconds on mainline and next, but not with this patchset. 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/
Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend
On Mon, 18 Mar 2013, Luis R. Rodriguez wrote: Note that what this will do is call later mod_timer() for rx_poll_timer, the right thing to do then, which would be equivalent to your patch is to modify the ath_start_rx_poll() to instead use the new API mod_timer_pending() added on v2.6.30 via commit 74019224. This would not re-arm the timer if it was previously removed. Thanks for the details Luis. Converting to mod_timer_pending() seems to do the trick as well. Parag -- 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] usb: Make USB persist default configurable
What drivers/devices don't work with persist? We need to know that now, otherwise all other distros and users have problems, right? We have seen a problem with the LTE modem in the Chromebook Pixel using the usb/serial/option.c driver, but we are not quite sure of the root cause yet. It occasionally seems to loose its power session due to autosuspend and then hit core/hub.c:check_port_resume_type(), where it gets the reset_resume flag if persist is enabled. However, since the option driver does not implement the (optional) reset_resume method, this eventually ends up leaving the device in a state where it is neither working nor getting cleanly reenumerated. We are still actively investigating that issue to figure out the underlying bug (not sure whether it is a general problem with drivers that do not implement reset_resume... also, we are still only on 3.4 and have not tried to confirm it on 3.8 yet). However, as we generally hadn't intended persist to be active and this had slipped through our (admittedly very crude) userspace implementation, I proposed this patch so that going forward our devices could always have the persist setting we intend for them at all times. -- 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/
