[RFC] arm64: Early printk support for virtio-mmio console devices.
From: Pranavkumar Sawargaonkar
This patch implements early printk support for virtio-mmio console devices
without using any hypercalls.
The current virtio early printk code in kernel expects that hypervisor will
provide some mechanism generally a hypercall to support early printk. This
patch does not break existing hypercall based early print support.
This implementation adds:
1. Early read-write register named early_rw in virtio console's config space.
2. Two host feature flags namely VIRTIO_CONSOLE_F_EARLY_READ and
VIRTIO_CONSOLE_F_EARLY_WRITE for telling guest about early-read and early-write
capability in console device.
Early write mechanism:
1. When a guest wants to out some character, it has to simply write the
character to early_rw register in config space of virtio console device.
Early read mechanism:
1. When a guest wants to in some character, it has to simply read the early_rw
register in config space of virtio console device. Lets say we get 32-bit value
X.
2. If most significant bit of X is set (i.e. X & 0x8000 == 0x8000) then
least significant 8 bits of X represents input charaacter else guest need to
try again reading early_rw register.
Note: This patch only includes kernel side changes for early printk, the
host/hypervisor side emulation of early_rw register is out of scope here.
Signed-off-by: Anup Patel
---
arch/arm64/kernel/early_printk.c| 24
include/uapi/linux/virtio_console.h |4
2 files changed, 28 insertions(+)
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index ac974f4..a82b5aa 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -25,6 +25,9 @@
#include
#include
+#include
+#include
+#include
static void __iomem *early_base;
static void (*printch)(char ch);
@@ -53,6 +56,26 @@ static void smh_printch(char ch)
}
/*
+ * VIRTIO MMIO based debug console.
+ */
+static void virtio_console_early_printch(char ch)
+{
+ u32 tmp;
+ struct virtio_console_config *p = early_base + VIRTIO_MMIO_CONFIG;
+
+ tmp = readl_relaxed(early_base + VIRTIO_MMIO_DEVICE_ID);
+ if (tmp != VIRTIO_ID_CONSOLE) {
+ return;
+ }
+
+ tmp = readl_relaxed(early_base + VIRTIO_MMIO_HOST_FEATURES);
+ if (!(tmp & (1 << VIRTIO_CONSOLE_F_EARLY_WRITE))) {
+ return;
+ }
+ writeb_relaxed(ch, >early_rw);
+}
+
+/*
* 8250/16550 (8-bit aligned registers) single character TX.
*/
static void uart8250_8bit_printch(char ch)
@@ -82,6 +105,7 @@ static const struct earlycon_match earlycon_match[]
__initconst = {
{ .name = "smh", .printch = smh_printch, },
{ .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
{ .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
+ { .name = "virtio-console", .printch = virtio_console_early_printch, },
{}
};
diff --git a/include/uapi/linux/virtio_console.h
b/include/uapi/linux/virtio_console.h
index ee13ab6..1171cb4 100644
--- a/include/uapi/linux/virtio_console.h
+++ b/include/uapi/linux/virtio_console.h
@@ -38,6 +38,8 @@
/* Feature bits */
#define VIRTIO_CONSOLE_F_SIZE 0 /* Does host provide console size? */
#define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple ports? */
+#define VIRTIO_CONSOLE_F_EARLY_READ 2 /* Does host support early read? */
+#define VIRTIO_CONSOLE_F_EARLY_WRITE 3 /* Does host support early write? */
#define VIRTIO_CONSOLE_BAD_ID (~(u32)0)
@@ -48,6 +50,8 @@ struct virtio_console_config {
__u16 rows;
/* max. number of ports this device can hold */
__u32 max_nr_ports;
+ /* early read/write register */
+ __u32 early_rw;
} __attribute__((packed));
/*
--
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/
[PATCH v2] Erroneous double irq_eoi() on CPM IRQ in MPC8xx
irq_eoi() is already called by generic_handle_irq() so
it shall not be called a again
Signed-off-by: Christophe Leroy
Index: linux/arch/powerpc/platforms/8xx/m8xx_setup.c
===
--- linux/arch/powerpc/platforms/8xx/m8xx_setup.c (revision 4802)
+++ linux/arch/powerpc/platforms/8xx/m8xx_setup.c (working copy)
@@ -218,19 +218,12 @@
static void cpm_cascade(unsigned int irq, struct irq_desc *desc)
{
- struct irq_chip *chip;
- int cascade_irq;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ int cascade_irq = cpm_get_irq();
- if ((cascade_irq = cpm_get_irq()) >= 0) {
- struct irq_desc *cdesc = irq_to_desc(cascade_irq);
-
+ if (cascade_irq >= 0)
generic_handle_irq(cascade_irq);
- chip = irq_desc_get_chip(cdesc);
- chip->irq_eoi(>irq_data);
- }
-
- chip = irq_desc_get_chip(desc);
chip->irq_eoi(>irq_data);
}
--
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: [RFT/PATCH 2/6] driver: serial: mpc52xx_uart: Remove "uart_console" defintion
On Thursday 18 April 2013 09:26 AM, Felipe Balbi wrote: On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote: Since "uart_console" definition is now moved to serial core haeder file . Serial drivers need not define them. Cc: Sylvain Munaut Cc: Santosh Shilimkar Cc: Felipe Balbi Cc: Rajendra nayak Signed-off-by: Sourav Poddar looks like it should be merged with previous patch to avoid redefinition errors. true..i can squash it with the previous patch. -- 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/
pull request: bluetooth-next 2013-04-18
Hi John,
A set of changes intended for 3.10. The biggest changes here are from David
Herrmann, he rewrote most of the HIDP layer making it more reliable. Marcel
added a driver setup stage for device that need special handling on their
early initialization. Other than that we have the usual clean ups, bugfixes
and small improvements.
Please pull or let me know of any problems! Thanks!
Gustavo
---
The following changes since commit 84bcc0c3c4b8ca4c0abed2d2dd63b7ce04f8be0e:
brcmfmac: enable sk_buff queueing when credits deplete (2013-04-03 15:07:09
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
for-upstream
for you to fetch changes up to 76a388beaf92cc75b829d4a0b7d69afaaeaa4b0a:
Bluetooth: Rename LE_SCANNING_* macros (2013-04-18 01:17:27 -0300)
Andre Guedes (7):
Bluetooth: Fix HCI request framework
Bluetooth: Fix hci_inquiry ioctl usage
Bluetooth: Remove unneeded hci_req_cmd_status function
Bluetooth: Change LE scanning timeout macros
Bluetooth: Add LE scan type macros
Bluetooth: Add macros for filter duplicates values
Bluetooth: Rename LE_SCANNING_* macros
Chan-yeol Park (3):
Bluetooth: Fix H4 crash from incoming UART packets
Bluetooth: Fix possible NULL dereference in hci_uart_tty_receive
Bluetooth: Remove trivial white space
Claudio Takahasi (5):
Bluetooth: Fix SCO connection reference
Bluetooth: Use GFP_KERNEL in sco_conn_add
Bluetooth: Minor coding style fix
Bluetooth: Remove unneeded parameter
Bluetooth: Reject SCO when hci connection timeouts
David Herrmann (18):
Bluetooth: hidp: remove redundant error message
Bluetooth: hidp: verify l2cap sockets
Bluetooth: rename hci_conn_put to hci_conn_drop
Bluetooth: remove unneeded hci_conn_hold/put_device()
Bluetooth: introduce hci_conn ref-counting
Bluetooth: hidp: remove unused session->state field
Bluetooth: hidp: test "terminate" before sleeping
Bluetooth: allow constant arguments for bacmp()/bacpy()
Bluetooth: hidp: move hidp_schedule() to core.c
Bluetooth: l2cap: introduce l2cap_conn ref-counting
Bluetooth: l2cap: add l2cap_user sub-modules
Bluetooth: hidp: add new session-management helpers
Bluetooth: hidp: remove old session-management
Bluetooth: hidp: handle kernel_sendmsg() errors correctly
Bluetooth: hidp: merge hidp_process_{ctrl,intr}_transmit()
Bluetooth: hidp: merge 'send' functions into hidp_send_message()
Bluetooth: hidp: don't send boot-protocol messages as HID-reports
Bluetooth: hidp: fix sending output reports on intr channel
Frédéric Dalleau (1):
Bluetooth: Move and rename hci_conn_accept
Jaganath Kanakkassery (1):
Bluetooth: Fix incorrect SSP mode bit for non SSP devices
Johan Hedberg (6):
Bluetooth: Track received events in hdev
Bluetooth: Add __hci_cmd_sync() helper function
Bluetooth: Add support for custom event terminated commands
Bluetooth: Add __hci_cmd_sync_ev function
Bluetooth: Track feature pages in a single table
Bluetooth: Add reading of all local feature pages
Marcel Holtmann (4):
Bluetooth: Add driver setup stage for early init
Bluetooth: Convert BCM92035 support to driver setup callback
Bluetooth: Remove driver init queue from core
Bluetooth: Use separate function for BCM92035 vendor setup
Noguchi Kazutosi (1):
Bluetooth: Add support for Foxconn/Hon Hai [0489:e04d]
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 41 +-
drivers/bluetooth/hci_h4.c| 3 +
drivers/bluetooth/hci_ldisc.c | 15 +-
include/net/bluetooth/bluetooth.h | 5 +-
include/net/bluetooth/hci.h | 9 +-
include/net/bluetooth/hci_core.h | 98 ++--
include/net/bluetooth/l2cap.h | 15 +
net/bluetooth/hci_conn.c | 38 +-
net/bluetooth/hci_core.c | 239 +++---
net/bluetooth/hci_event.c | 184
net/bluetooth/hci_sysfs.c | 17 +-
net/bluetooth/hidp/core.c | 992
+++-
net/bluetooth/hidp/hidp.h | 67 ++-
net/bluetooth/hidp/sock.c | 22 +-
net/bluetooth/l2cap_core.c| 127 -
net/bluetooth/l2cap_sock.c| 6 +
net/bluetooth/mgmt.c | 17 +-
net/bluetooth/sco.c | 49 +-
net/bluetooth/smp.c | 2 +-
20 files changed, 1213 insertions(+), 735 deletions(-)
pgpS_dNu1skTy.pgp
Description: PGP signature
Re: [PATCH v2] media: davinci: vpif: align the buffers size to page page size boundary
Hi Marek, On Tue, Apr 16, 2013 at 4:48 PM, Laurent Pinchart wrote: > Hi Prabhakar, > > (CC'ing Marek) > > On Tuesday 16 April 2013 16:24:30 Prabhakar lad wrote: >> From: Lad, Prabhakar >> >> with recent commit with id 068a0df76023926af958a336a78bef60468d2033 >> which adds add length check for mmap, the application were failing to >> mmap the buffers. >> >> This patch aligns the the buffer size to page size boundary for both >> capture and display driver so the it pass the check. >> >> Signed-off-by: Lad, Prabhakar >> Cc: Laurent Pinchart >> Cc: Hans Verkuil >> Cc: Mauro Carvalho Chehab >> --- >> Changes for v2: >> 1: Fixed a typo in commit message. >> >> drivers/media/platform/davinci/vpif_capture.c |1 + >> drivers/media/platform/davinci/vpif_display.c |1 + >> 2 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c index 5f98df1..25981d6 >> 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -183,6 +183,7 @@ static int vpif_buffer_queue_setup(struct vb2_queue *vq, >> *nbuffers = config_params.min_numbuffers; >> >> *nplanes = 1; >> + size = PAGE_ALIGN(size); > > I wonder if that's the best fix. > > The queue_setup operation is supposed to return the size required by the > driver for each plane. Depending on the hardware requirements, that size might > not be a multiple of the page size. > > As we can't mmap() a fraction of a page, the allocated plane size needs to be > rounded up to the next page boundary to allow mmap() support. The dma-contig > and dma-sg allocators already do so in their alloc operation, but the vmalloc > allocator doesn't. > > The recent "media: vb2: add length check for mmap" patch verifies that the > mmap() size requested by userspace doesn't exceed the buffer size. As the > mmap() size is rounded up to the next page boundary the check will fail for > buffer sizes that are not multiple of the page size. > > Your fix will not result in overallocation (as the allocator already rounds > the size up), but will prevent the driver from importing a buffer large enough > for the hardware but not rounded up to the page size. > > A better fix might be to round up the buffer size in the buffer size check at > mmap() time, and fix the vmalloc allocator to round up the size. That the > allocator, not drivers, is responsible for buffer size alignment should be > documented in videobuf2-core.h. > Do you plan to post a patch fixing it as per Laurent's suggestion ? Regards, --Prabhakar >> sizes[0] = size; >> alloc_ctxs[0] = common->alloc_ctx; >> >> diff --git a/drivers/media/platform/davinci/vpif_display.c >> b/drivers/media/platform/davinci/vpif_display.c index 1b3fb5c..3414715 >> 100644 >> --- a/drivers/media/platform/davinci/vpif_display.c >> +++ b/drivers/media/platform/davinci/vpif_display.c >> @@ -162,6 +162,7 @@ static int vpif_buffer_queue_setup(struct vb2_queue *vq, >> *nbuffers = config_params.min_numbuffers; >> >> *nplanes = 1; >> + size = PAGE_ALIGN(size); >> sizes[0] = size; >> alloc_ctxs[0] = common->alloc_ctx; >> return 0; > > -- > Regards, > > Laurent Pinchart > -- 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/
[Suggestion] PowerPC: kernel: memory access violation when rtas_data_buf contents are more than 1026
Hello Maintainers:
in arch/powerpc/kernel/lparcfg.c, parse_system_parameter_string()
need set '\0' for 'local_buffer'.
the reason is:
SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096
the contents of rtas_data_buf may truncated in memcpy (line 301).
if contents are truncated.
the splpar_strlen is more than 1026 (line 321)
the while loop checking will not find the end of buffer (line 326)
it will cause memory access violation.
I find it by reading code, so please help check.
thanks.
gchen.
-related fix patch--
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index 801a757..d92f387 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -299,6 +299,7 @@ static void parse_system_parameter_string(struct seq_file
*m)
__pa(rtas_data_buf),
RTAS_DATA_BUF_SIZE);
memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
+ local_buffer[SPLPAR_MAXLENGTH - 1] = '\0';
spin_unlock(_data_buf_lock);
if (call_status != 0) {
-related source code
283 static void parse_system_parameter_string(struct seq_file *m)
284 {
285 int call_status;
286
287 unsigned char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
288 if (!local_buffer) {
289 printk(KERN_ERR "%s %s kmalloc failure at line %d\n",
290__FILE__, __func__, __LINE__);
291 return;
292 }
293
294 spin_lock(_data_buf_lock);
295 memset(rtas_data_buf, 0, SPLPAR_MAXLENGTH);
296 call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3,
1,
297 NULL,
298 SPLPAR_CHARACTERISTICS_TOKEN,
299 __pa(rtas_data_buf),
300 RTAS_DATA_BUF_SIZE);
301 memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
302 spin_unlock(_data_buf_lock);
303
304 if (call_status != 0) {
305 printk(KERN_INFO
306"%s %s Error calling get-system-parameter (0x%x)\n",
307__FILE__, __func__, call_status);
308 } else {
309 int splpar_strlen;
310 int idx, w_idx;
311 char *workbuffer = kzalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
312 if (!workbuffer) {
313 printk(KERN_ERR "%s %s kmalloc failure at line
%d\n",
314__FILE__, __func__, __LINE__);
315 kfree(local_buffer);
316 return;
317 }
318 #ifdef LPARCFG_DEBUG
319 printk(KERN_INFO "success calling get-system-parameter\n");
320 #endif
321 splpar_strlen = local_buffer[0] * 256 + local_buffer[1];
322 local_buffer += 2; /* step over strlen value */
323
324 w_idx = 0;
325 idx = 0;
326 while ((*local_buffer) && (idx < splpar_strlen)) {
327 workbuffer[w_idx++] = local_buffer[idx++];
328 if ((local_buffer[idx] == ',')
329 || (local_buffer[idx] == '\0')) {
330 workbuffer[w_idx] = '\0';
331 if (w_idx) {
332 /* avoid the empty string */
333 seq_printf(m, "%s\n", workbuffer);
334 }
335 memset(workbuffer, 0, SPLPAR_MAXLENGTH);
336 idx++; /* skip the comma */
337 w_idx = 0;
338 } else if (local_buffer[idx] == '=') {
339 /* code here to replace workbuffer contents
340with different keyword strings */
341 if (0 == strcmp(workbuffer, "MaxEntCap")) {
342 strcpy(workbuffer,
343
"partition_max_entitled_capacity");
344 w_idx = strlen(workbuffer);
345 }
346 if (0 == strcmp(workbuffer,
"MaxPlatProcs")) {
347 strcpy(workbuffer,
348
"system_potential_processors");
349 w_idx = strlen(workbuffer);
350 }
351 }
352 }
353 kfree(workbuffer);
354 local_buffer -=
Re: [PATCH 1/4] mfd: Kontron PLD mfd driver
On Wed, 2013-04-17 at 21:19 -0700, Guenter Roeck wrote:
> On Sat, Apr 13, 2013 at 10:38:07PM +0200, Thomas Gleixner wrote:
> > > + return kempld_read8(pld, index) | kempld_read8(pld, index+1) << 8;
> > index + 1)
> > Please
> Wondering why does checkpatch not report those ?
because checkpatch doesn't care about spacing around
arithmetic as long as it's consistent.
Documentation/CodingStyle doesn't say anything about
it either.
Look around checkpatch line 2654
} elsif ($op eq '<<' or $op eq '>>' or
$op eq '&' or $op eq '^' or $op eq '|'
or
$op eq '+' or $op eq '-' or
$op eq '*' or $op eq '/' or
$op eq '%')
{
if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
ERROR("SPACING",
"need consistent spacing
around '$op' $at\n" .
$hereptr);
}
--
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/4] mfd: Kontron PLD mfd driver
On Sat, Apr 13, 2013 at 10:38:07PM +0200, Thomas Gleixner wrote: [ ... ] > > > + return kempld_read8(pld, index) | kempld_read8(pld, index+1) << 8; > > index + 1) > Please > Wondering why does checkpatch not report those ? I just reviewed another driver with the same kind of problem, and checkpatch is just as silent. There seems to be a whole class of expressions where it does not complain about missing spaces. Joe, any idea ? Thanks, Guenter -- 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: [NEW DRIVER V5 6/7] drivers/hwmon: DA9058 HWMON driver
On Wed, Apr 17, 2013 at 05:33:36PM +0100, Anthony Olech wrote: > This patch is relative to linux next-20130417 > > This is the HWMON component driver of the Dialog DA9058 PMIC. > This driver is just one component of the whole DA9058 PMIC driver. > It depends on the CORE and ADC component drivers of the DA9058 MFD. > > Changes relative to V3 of this patch: > - rebased to latest tagged linux-next - previously relative to mainline > Documentation/hwmon/da9058 > - added final NL > drivers/hwmon/Kconfig > - changed dependancy from I2C to MFD > drivers/hwmon/Makefile > - put in alphabetical order > drivers/hwmon/da9058-hwmon.c > - aligned subsequent lines of function declarations > - used single function for all slow labels > - used recommended ..._label as function name > - error conditions are returned as negative integers > - chaned to suggested return value casting > - removed all constant sysfile atributes except the labels > - corrected parameter to adc read function to unsigned > - used suggest name 'input' instead of 'value' > - changed first temp attribute to temp1 > - fixed expression error to boolean and from bitwise and > - removed redundant return statement > - removed race condition by initializing before create sysfs > - corected alignments on broken long lines > > Signed-off-by: Anthony Olech > Signed-off-by: David Dajun Chen > --- > Documentation/hwmon/da9058 | 39 + > drivers/hwmon/Kconfig| 10 ++ > drivers/hwmon/Makefile |3 +- > drivers/hwmon/da9058-hwmon.c | 349 > ++ > 4 files changed, 400 insertions(+), 1 deletion(-) > create mode 100644 Documentation/hwmon/da9058 > create mode 100644 drivers/hwmon/da9058-hwmon.c > > diff --git a/Documentation/hwmon/da9058 b/Documentation/hwmon/da9058 > new file mode 100644 > index 000..eaedfe7 > --- /dev/null > +++ b/Documentation/hwmon/da9058 > @@ -0,0 +1,39 @@ > +Kernel driver da9058-hwmon > +== > + > +Supported chips: > + * Dialog Semiconductor DA9058 PMIC > +Prefix: 'da9058' > +Datasheet: > + http://www.dialog-semiconductor.com/products/power-management/da9058 > + > +Authors: Opensource [Anthony Olech] > + > +Description > +--- > + > +The DA9058 PMIC contains a 5 channel ADC which can be used to monitor a > +range of system operating parameters, including the battery voltage and > +temperature. The ADC measures voltage, but two of the ADC channels can > +be configured to supply a current, so that if an NTC termister is connected > +then the voltage reading can be converted to a temperature. Currently the > +driver provides reporting of all the input values but does not provide any > +alarms. > + > +Voltage Monitoring > +-- > + > +Voltages are sampled in either 'automatic' or 'manual' mode, which is an > +initialization parameter set in the platform data by the machine driver. > +In manual mode the ADC conversion is 12 bit and in automatic mode it is > +10 bit. However all the raw readings are reported as 12 bit numbers. > + > +Physical Limits > +--- > + > +vbat 2500 - 4500 milliVolts > +tbat 0- 2500 milliVolts > +adc0- 2500 milliVolts > +vfpin 0- 4095 milliVolts > +tjunc there is a correction factor programmed during manufacturing > + > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index da93094..8014af2 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -324,6 +324,16 @@ config SENSORS_ATXP1 > This driver can also be built as a module. If so, the module > will be called atxp1. > > +config SENSORS_DA9058 > + tristate "Dialog Semiconductor DA9058 ADC" > + depends on MFD_DA9058 && DA9058_ADC > + help > + If you say yes here you get support for the hardware monitoring > + functionality of the Dialog Semiconductor DA9058 PMIC. > + > + This driver can also be built as a module. If so, the module > + will be called da9058-hwmon. > + > config SENSORS_DS620 > tristate "Dallas Semiconductor DS620" > depends on I2C > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index c51b0dc..5b7705a 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -46,7 +46,8 @@ obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o > obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o > obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o > obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o > -obj-$(CONFIG_SENSORS_DA9055)+= da9055-hwmon.o > +obj-$(CONFIG_SENSORS_DA9055) += da9055-hwmon.o >
Re: [PATCH -next] ALSA: hda - fix error return code in patch_alc662()
Sorry, i miss something..
Thanks,
wang
> Hello Wei,
>
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -3787,7 +3787,8 @@ static int patch_alc662(struct hda_codec *codec)
> if ((alc_get_coef0(codec) & (1 << 14)) &&
> codec->bus->pci->subsystem_vendor == 0x1025 &&
> spec->cdefine.platform_type == 1) {
> - if (alc_codec_rename(codec, "ALC272X") < 0)
>
> I don't think we should fix this problem. And your changelog is wrong!
>
> Thanks,
> Wang
> + err = alc_codec_rename(codec, "ALC272X");
> + if (err < 0)
> goto 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/
Re:[PATCH -next] ALSA: hda - fix error return code in patch_alc662()
Hello Wei,
+++ b/sound/pci/hda/patch_realtek.c
@@ -3787,7 +3787,8 @@ static int patch_alc662(struct hda_codec *codec)
if ((alc_get_coef0(codec) & (1 << 14)) &&
codec->bus->pci->subsystem_vendor == 0x1025 &&
spec->cdefine.platform_type == 1) {
- if (alc_codec_rename(codec, "ALC272X") < 0)
I don't think we should fix this problem. And your changelog is wrong!
Thanks,
Wang
+ err = alc_codec_rename(codec, "ALC272X");
+ if (err < 0)
goto 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/
Re: [PATCH v3 15/15] KVM: MMU: replace kvm_zap_all with kvm_mmu_invalid_all_pages
On 04/18/2013 08:08 AM, Marcelo Tosatti wrote: > On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote: >> Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and >> rename kvm_zap_all to kvm_free_all which is used to free all >> memmory used by kvm mmu when vm is being destroyed, at this time, >> no vcpu exists and mmu-notify has been unregistered, so we can >> free the shadow pages out of mmu-lock > > Since there is no contention for mmu-lock its also not a problem to > grab the lock right? This still has contention. Other mmu-notify can happen when we handle ->release(). On the other handle, spin-lock is not preemptable. > > Automated verification of locking/srcu might complain. We hold slot-lock to free shadow page out of mmu-lock, it can avoid the complain. No? -- 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 12/15] KVM: MMU: fast invalid all shadow pages
On 04/18/2013 08:05 AM, Marcelo Tosatti wrote:
> On Tue, Apr 16, 2013 at 02:32:50PM +0800, Xiao Guangrong wrote:
>> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
>> walk and zap all shadow pages one by one, also it need to zap all guest
>> page's rmap and all shadow page's parent spte list. Particularly, things
>> become worse if guest uses more memory or vcpus. It is not good for
>> scalability.
>>
>> In this patch, we introduce a faster way to invalid all shadow pages.
>> KVM maintains a global mmu invalid generation-number which is stored in
>> kvm->arch.mmu_valid_gen and every shadow page stores the current global
>> generation-number into sp->mmu_valid_gen when it is created.
>>
>> When KVM need zap all shadow pages sptes, it just simply increase the
>> global generation-number then reload root shadow pages on all vcpus.
>> Vcpu will create a new shadow page table according to current kvm's
>> generation-number. It ensures the old pages are not used any more.
>>
>> The invalid-gen pages (sp->mmu_valid_gen != kvm->arch.mmu_valid_gen)
>> are keeped in mmu-cache until page allocator reclaims page.
>>
>> If the invalidation is due to memslot changed, its rmap amd lpage-info
>> will be freed soon, in order to avoiding use invalid memory, we unmap
>> all sptes on its rmap and always reset the large-info all memslots so
>> that rmap and lpage info can be safely freed.
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>> arch/x86/include/asm/kvm_host.h |2 +
>> arch/x86/kvm/mmu.c | 85
>> +-
>> arch/x86/kvm/mmu.h |4 ++
>> arch/x86/kvm/x86.c |6 +++
>> 4 files changed, 94 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h
>> b/arch/x86/include/asm/kvm_host.h
>> index 1ad9a34..6f8ee18 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -223,6 +223,7 @@ struct kvm_mmu_page {
>> int root_count; /* Currently serving as active root */
>> unsigned int unsync_children;
>> unsigned long parent_ptes; /* Reverse mapping for parent_pte */
>> +unsigned long mmu_valid_gen;
>> DECLARE_BITMAP(unsync_child_bitmap, 512);
>>
>> #ifdef CONFIG_X86_32
>> @@ -531,6 +532,7 @@ struct kvm_arch {
>> unsigned int n_requested_mmu_pages;
>> unsigned int n_max_mmu_pages;
>> unsigned int indirect_shadow_pages;
>> +unsigned long mmu_valid_gen;
>> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
>> /*
>> * Hash table of struct kvm_mmu_page.
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index 9ac584f..12129b7 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -1732,6 +1732,11 @@ static struct rmap_operations invalid_rmap_ops = {
>> .rmap_unmap = kvm_unmap_invalid_rmapp
>> };
>>
>> +static void init_invalid_memslot_rmap_ops(struct kvm_memory_slot *slot)
>> +{
>> +slot->arch.ops = _rmap_ops;
>> +}
>> +
>> typedef void (*handle_rmap_fun)(unsigned long *rmapp, void *data);
>> static void walk_memslot_rmap_nolock(struct kvm_memory_slot *slot,
>> handle_rmap_fun fun, void *data)
>> @@ -1812,6 +1817,65 @@ void free_meslot_rmap_desc_nolock(struct
>> kvm_memory_slot *slot)
>> walk_memslot_rmap_nolock(slot, free_rmap_desc_nolock, NULL);
>> }
>>
>> +/*
>> + * Fast invalid all shadow pages belong to @slot.
>> + *
>> + * @slot != NULL means the invalidation is caused the memslot specified
>> + * by @slot is being deleted, in this case, we should ensure that rmap
>> + * and lpage-info of the @slot can not be used after calling the function.
>> + * Specially, if @slot is INVALID_ALL_SLOTS, all slots will be deleted
>> + * soon, it always happens when kvm is being destroyed.
>> + *
>> + * @slot == NULL means the invalidation due to other reasons, we need
>> + * not care rmap and lpage-info since they are still valid after calling
>> + * the function.
>> + */
>> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
>> + struct kvm_memory_slot *slot)
>> +{
>> +struct kvm_memory_slot *each_slot;
>> +
>> +spin_lock(>mmu_lock);
>> +kvm->arch.mmu_valid_gen++;
>> +
>> +if (slot == INVALID_ALL_SLOTS)
>> +kvm_for_each_memslot(each_slot, kvm_memslots(kvm))
>> +init_invalid_memslot_rmap_ops(each_slot);
>> +else if (slot)
>> +init_invalid_memslot_rmap_ops(slot);
>> +
>> +/*
>> + * All shadow paes are invalid, reset the large page info,
>> + * then we can safely desotry the memslot, it is also good
>> + * for large page used.
>> + */
>> +kvm_clear_all_lpage_info(kvm);
>> +
>> +/*
>> + * Notify all vcpus to reload its shadow page table
>> + * and flush TLB. Then all vcpus will switch to new
>> + * shadow page table with the new mmu_valid_gen.
>> + *
>> + * Note: we should do this under
Re: [PATCH 3/6] driver: serial: omap: add prepare/complete callback for "no_console_suspend" case
Hi,
On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
> @@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops =
> {
> SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
> SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
> serial_omap_runtime_resume, NULL)
> + .prepare= serial_omap_prepare,
> + .complete = serial_omap_complete,
if CONFIG_PM_SLEEP isn't defined, this will break compilation.
--
balbi
signature.asc
Description: Digital signature
Re: [RFT/PATCH 2/6] driver: serial: mpc52xx_uart: Remove "uart_console" defintion
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote: > Since "uart_console" definition is now moved to serial core > haeder file . Serial drivers need not define them. > > Cc: Sylvain Munaut > Cc: Santosh Shilimkar > Cc: Felipe Balbi > Cc: Rajendra nayak > Signed-off-by: Sourav Poddar looks like it should be merged with previous patch to avoid redefinition errors. -- balbi signature.asc Description: Digital signature
Re: [PATCH] powerpc: Add HWCAP2 aux entry
akpm,
If you're happy with this, is it something you can take in your tree?
Mikey
Michael Neuling wrote:
> We are currently out of free bits in AT_HWCAP. With POWER8, we have
> several hardware features that we need to advertise.
>
> Tested on POWER and x86.
>
> Signed-off-by: Michael Neuling
> Signed-off-by: Nishanth Aravamudan
> ---
>
> > Wouldn't it be safer to not emit AT_HWCAP2 unless it is defined by the arch?
> >
> > That way the change would only impact powerpc.
>
> Should be addressed with this version.
>
> Mikey
>
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index fb3245e..ccadad6 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -52,6 +52,7 @@ struct cpu_spec {
> char*cpu_name;
> unsigned long cpu_features; /* Kernel features */
> unsigned intcpu_user_features; /* Userland features */
> + unsigned intcpu_user_features2; /* Userland features v2 */
> unsigned intmmu_features; /* MMU features */
>
> /* cache line sizes */
> diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
> index ac9790f..cc0655a 100644
> --- a/arch/powerpc/include/asm/elf.h
> +++ b/arch/powerpc/include/asm/elf.h
> @@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
> instruction set this cpu supports. This could be done in userspace,
> but it's not easy, and we've already done it here. */
> # define ELF_HWCAP (cur_cpu_spec->cpu_user_features)
> +# define ELF_HWCAP2 (cur_cpu_spec->cpu_user_features2)
>
> /* This yields a string that ld.so will use to load implementation
> specific libraries for optimization. This is more specific in
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 3939829..1f8b5d5 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -240,6 +240,9 @@ create_elf_tables(struct linux_binprm *bprm, struct
> elfhdr *exec,
> NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
> NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
> NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
> +#ifdef ELF_HWCAP2
> + NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> +#endif
> NEW_AUX_ENT(AT_EXECFN, bprm->exec);
> if (k_platform) {
> NEW_AUX_ENT(AT_PLATFORM,
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index 9c13e02..bf2381d 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -483,7 +483,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
> *bprm,
> size_t platform_len = 0, len;
> char *k_platform, *k_base_platform;
> char __user *u_platform, *u_base_platform, *p;
> - long hwcap;
> int loop;
> int nr; /* reset for each csp adjustment */
>
> @@ -502,8 +501,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
> *bprm,
> return -EFAULT;
> #endif
>
> - hwcap = ELF_HWCAP;
> -
> /*
>* If this architecture has a platform capability string, copy it
>* to userspace. In some cases (Sparc), this info is impossible
> @@ -617,7 +614,10 @@ static int create_elf_fdpic_tables(struct linux_binprm
> *bprm,
>
> nr = 0;
> csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
> - NEW_AUX_ENT(AT_HWCAP, hwcap);
> + NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> +#ifdef ELF_HWCAP2
> + NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> +#endif
> NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
> NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
> NEW_AUX_ENT(AT_PHDR,exec_params->ph_addr);
> diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
> index 61594d5..835c065 100644
> --- a/include/uapi/linux/auxvec.h
> +++ b/include/uapi/linux/auxvec.h
> @@ -28,6 +28,7 @@
> #define AT_BASE_PLATFORM 24 /* string identifying real platform, may
>* differ from AT_PLATFORM. */
> #define AT_RANDOM 25 /* address of 16 random bytes */
> +#define AT_HWCAP2 26 /* extension of AT_HWCAP */
>
> #define AT_EXECFN 31/* filename of program */
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
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] powerpc: Add HWCAP2 aux entry
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise.
Tested on POWER and x86.
Signed-off-by: Michael Neuling
Signed-off-by: Nishanth Aravamudan
---
> Wouldn't it be safer to not emit AT_HWCAP2 unless it is defined by the arch?
>
> That way the change would only impact powerpc.
Should be addressed with this version.
Mikey
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fb3245e..ccadad6 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -52,6 +52,7 @@ struct cpu_spec {
char*cpu_name;
unsigned long cpu_features; /* Kernel features */
unsigned intcpu_user_features; /* Userland features */
+ unsigned intcpu_user_features2; /* Userland features v2 */
unsigned intmmu_features; /* MMU features */
/* cache line sizes */
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index ac9790f..cc0655a 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
instruction set this cpu supports. This could be done in userspace,
but it's not easy, and we've already done it here. */
# define ELF_HWCAP (cur_cpu_spec->cpu_user_features)
+# define ELF_HWCAP2(cur_cpu_spec->cpu_user_features2)
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..1f8b5d5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -240,6 +240,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_EXECFN, bprm->exec);
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9c13e02..bf2381d 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -483,7 +483,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
size_t platform_len = 0, len;
char *k_platform, *k_base_platform;
char __user *u_platform, *u_base_platform, *p;
- long hwcap;
int loop;
int nr; /* reset for each csp adjustment */
@@ -502,8 +501,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
return -EFAULT;
#endif
- hwcap = ELF_HWCAP;
-
/*
* If this architecture has a platform capability string, copy it
* to userspace. In some cases (Sparc), this info is impossible
@@ -617,7 +614,10 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
nr = 0;
csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
- NEW_AUX_ENT(AT_HWCAP, hwcap);
+ NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
NEW_AUX_ENT(AT_PHDR,exec_params->ph_addr);
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index 61594d5..835c065 100644
--- a/include/uapi/linux/auxvec.h
+++ b/include/uapi/linux/auxvec.h
@@ -28,6 +28,7 @@
#define AT_BASE_PLATFORM 24/* string identifying real platform, may
* differ from AT_PLATFORM. */
#define AT_RANDOM 25 /* address of 16 random bytes */
+#define AT_HWCAP2 26 /* extension of AT_HWCAP */
#define AT_EXECFN 31 /* filename of program */
--
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 097/102] efivars: explicitly calculate length of VariableName
On 04/17/2013 09:28 PM, Luis Henriques wrote: > On Wed, Apr 17, 2013 at 08:13:57PM +0800, Lingzhu Xiang wrote: >> On 04/17/2013 07:56 PM, Andy Whitcroft wrote: >>> On Wed, Apr 17, 2013 at 12:37:43PM +0800, Lingzhu Xiang wrote: On 04/16/2013 06:33 PM, Luis Henriques wrote: > 68d929862e29a8b52a7f2f2f86a0600423b093cd efi: be more paranoid about > available space when creating variables This prevents a bricking issue for some Samsung devices but causes regression on many other machines. https://bugzilla.kernel.org/show_bug.cgi?id=55471 https://bugzilla.redhat.com/show_bug.cgi?id=947142 http://article.gmane.org/gmane.linux.kernel.efi/1078 http://article.gmane.org/gmane.linux.kernel.stable/47150 This patchset will fix it again: http://thread.gmane.org/gmane.linux.kernel.efi/1081 >>> >>> Thanks for the pointer. I note that in that thread you yourself imply >>> there are still issues after applying them? Was that accurate, is there >>> yet further patches needed? >> >> I just find that issue. Didn't see that when writing the above. >> >> Earlier I was testing on a different machine and the result was >> good. I guess the patch still needs some more testing. > > Thanks Lingzhu. > > So, I guess you would recommend me to drop the whole series until we > have this patchset accepted, tested and back-ported for 3.5, correct? > > (I tried to isolate the one you pointed out, but I'm afraid there are > too many dependencies between them to drop a single patch.) Unfortunately yes. The whole series are mostly solving pstore bugs and pstore trashing firmware. If you want to prevent more bricking from happening asap, a temporary choice is to allow disabling efi pstore altogether with these: ed9dc8ce7a1c8115dba9483a9b51df8b63a2e0ef efivars: Allow disabling use as a pstore backend ec0971ba5372a4dfa753f232449d23a8fd98490e efivars: Add module parameter to disable use as a pstore backend ca0ba26fbbd2d81c43085df49ce0abfe34535a90 efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE -- 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/5] fuse: close file synchronously
On 4/17/13 1:53 PM, Miklos Szeredi wrote: On Mon, Apr 15, 2013 at 5:30 PM, Miklos Szeredi wrote: Let's approach it from the other direction: what if you give back the write lease on the first flush? It will probably work fine for 99% of cases, since no other writes are going to happen after the first flush. For the remaining cases you'll just have to reacquire the lease when a write happens after the flush. I guess performance-wise that will not be an issue, but I may be wrong. What about this? We'd like to do it, but we can't. Firstly because we rely on the fact that the file cannot be modified by someone else while we hold exclusive write lease. By the time we decide to reacquire the lease, the file can be re-used by someone else and become completely different comparatively with its state at the moment of first flush. Secondly, we can't sensibly handle a case when the lease is already acquired by someone else by the time of attempt to reacquire it. Thanks, Maxim -- 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 net-next tree with the infiniband tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/infiniband/hw/cxgb4/qp.c between commit 5b0c275926b8
("RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled") from the
infiniband tree and commit 9919d5bd01b9 ("RDMA/cxgb4: Fix onchip queue
support for T5") from the net-next tree.
I think that they are 2 different fixes for the same problem, so I just
used the net-next version and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxxN48BdBZq.pgp
Description: PGP signature
Re: [PATCH v3 07/15] KVM: MMU: introduce invalid rmap handlers
On 04/18/2013 07:38 AM, Marcelo Tosatti wrote: > On Tue, Apr 16, 2013 at 02:32:45PM +0800, Xiao Guangrong wrote: >> Invalid rmaps is the rmap of the invalid memslot which is being >> deleted, especially, we can treat all rmaps are invalid when >> kvm is being destroyed since all memslot will be deleted soon. >> MMU should remove all sptes on these rmaps before the invalid >> memslot fully deleted >> >> The reason why we separately handle invalid rmap is we want to >> unmap invalid-rmap out of mmu-lock to achieve scale performance >> on intensive memory and vcpu used guest > > Better try to make the code simpler, and introduce complexity only > if necessary. Marcelo, This code is necessary to implement "unmap invalid rmap out of mmu-lock", the reason why we need it is that ... > > The idea to zap the roots is very elegant and apparently effective. What > are its problems? I mentioned it in 00/15: * Challenges Some page invalidation is requested when memslot is moved or deleted and kvm is being destroy who call zap_all_pages to delete all sp using their rmap and lpage-info, after call zap_all_pages, the rmap and lpage-info will be freed. So, we should implement a fast way to delete sp from the rmap and lpage-info. -- 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 -next] spi: omap2-mcspi: fix error return code in omap2_mcspi_probe()
From: Wei Yongjun Fix to return a negative error code from the error handling case instead of 0, as returned elsewhere in this function. Signed-off-by: Wei Yongjun --- drivers/spi/spi-omap2-mcspi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index 893c3d7..c31a1c0 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1277,7 +1277,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev) pm_runtime_set_autosuspend_delay(>dev, SPI_AUTOSUSPEND_TIMEOUT); pm_runtime_enable(>dev); - if (status || omap2_mcspi_master_setup(mcspi) < 0) + status = omap2_mcspi_master_setup(mcspi); + if (status < 0) goto disable_pm; status = spi_register_master(master); -- 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 -next] ALSA: hda - fix error return code in patch_alc662()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
sound/pci/hda/patch_realtek.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f15c36b..a3965b0 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3787,7 +3787,8 @@ static int patch_alc662(struct hda_codec *codec)
if ((alc_get_coef0(codec) & (1 << 14)) &&
codec->bus->pci->subsystem_vendor == 0x1025 &&
spec->cdefine.platform_type == 1) {
- if (alc_codec_rename(codec, "ALC272X") < 0)
+ err = alc_codec_rename(codec, "ALC272X");
+ if (err < 0)
goto 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/
Re: [PATCH v3] watchdog: Add hook for kicking in kdump path
On Wed, Apr 17, 2013 at 02:49:59PM -0700, Eric W. Biederman wrote: > Don Zickus writes: > > > A common problem with kdump is that during the boot up of the > > second kernel, the hardware watchdog times out and reboots the > > machine before a vmcore can be captured. > > > > Instead of tellling customers to disable their hardware watchdog > > timers, I hacked up a hook to put in the kdump path that provides > > one last kick before jumping into the second kernel. > > > > The assumption is the watchdog timeout is at least 10-30 seconds > > long, enough to get the second kernel to userspace to kick the watchdog > > again, if needed. > > Why not double the watchdog timeout? and/or pet the watchdog a little > more frequently. > > This is the least icky hook I have seen proposed to be put on the kexec > on panic path, but I still suspect this may reduce the ability to take a > crash dump. What happens if it was the watchdog timer that panic'd for > example. > That should be addressed by the use of mutex_trylock(), which should fail in that case. Guenter -- 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 v4 3/4] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
On Wed, 2013-04-17 at 15:23 -0400, Waiman Long wrote: > The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned > on) allow multiple tasks to spin on a single mutex concurrently. A > potential problem with the current approach is that when the mutex > becomes available, all the spinning tasks will try to acquire the > mutex more or less simultaneously. As a result, there will be a lot of > cacheline bouncing especially on systems with a large number of CPUs. > > This patch tries to reduce this kind of contention by putting the > mutex spinners into a queue so that only the first one in the queue > will try to acquire the mutex. This will reduce contention and allow > all the tasks to move forward faster. > > The queuing of mutex spinners is done using an MCS lock based > implementation which will further reduce contention on the mutex > cacheline than a similar ticket spinlock based implementation. This > patch will add a new field into the mutex data structure for holding > the MCS lock. This expands the mutex size by 8 bytes for 64-bit system > and 4 bytes for 32-bit system. This overhead will be avoid if the > MUTEX_SPIN_ON_OWNER option is turned off. > > The following table shows the jobs per minute (JPM) scalability data > on an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl > command is used to restrict the running of the fserver workloads to > 1/2/4/8 nodes with hyperthreading off. [...] > > The short workload is the only one that shows a decline in performance > probably due to the spinner locking and queuing overhead. > > Signed-off-by: Waiman Long > Acked-by: Rik van Riel Reviewed-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
On 04/17/2013 05:37 PM, Anshuman Khandual wrote:
> On 04/17/2013 12:38 PM, Michael Ellerman wrote:
>> On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
>>> This patch provides basic enablement for perf branch stack sampling
>>> framework
>>> on POWER8 processor with a new PMU feature called BHRB (Branch History
>>> Rolling
>>> Buffer).
>>>
>>> Signed-off-by: Anshuman Khandual
>>> ---
>>> arch/powerpc/perf/core-book3s.c | 96
>>> +++--
>>> arch/powerpc/perf/perf_event_bhrb.c | 85
>>> 2 files changed, 178 insertions(+), 3 deletions(-)
>>> create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
>>>
>>> diff --git a/arch/powerpc/perf/core-book3s.c
>>> b/arch/powerpc/perf/core-book3s.c
>>> index 4ac6e64..f4d1347 100644
>>> --- a/arch/powerpc/perf/core-book3s.c
>>> +++ b/arch/powerpc/perf/core-book3s.c
>>> @@ -19,6 +19,8 @@
>>> #include
>>> #include
>>>
>>> +#define BHRB_MAX_ENTRIES 32
>>> +
>>> struct cpu_hw_events {
>>> int n_events;
>>> int n_percpu;
>>> @@ -38,11 +40,21 @@ struct cpu_hw_events {
>>>
>>> unsigned int group_flag;
>>> int n_txn_start;
>>> +
>>> + /* BHRB bits */
>>> + u64 bhrb_filter;/* BHRB HW branch
>>> filter */
>>> + int bhrb_users;
>>> + void*bhrb_context;
>>> + struct perf_branch_stack bhrb_stack;
>>> + struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
>>> };
>>> +
>>> DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
>>>
>>> struct power_pmu *ppmu;
>>>
>>> +#include "perf_event_bhrb.c"
>>> +
>>
>> Um, why are you doing that?
>>
>
> There was no specific reason for that.
>
Ahh, I remember it now. The function in the new file uses "cpu_hw_events"
structure
which is passed during "record_and_restart" data capture phase. Right now
cpu_hw_events is
not defined in the header file but inside core-book3s.c itself. Solution to
this problem
could be any of these.
(0) Move all the code from the new file perf_event_bhrb.c into core-book3s.c
(1) Move cpu_hw_events structure to perf_event_server.h
(2) Create additional BHRB processing function inside struct power_pmu and
define it for P8 inside power8_pmu.c
Regards
Anshuman
--
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 12/15] KVM: MMU: fast invalid all shadow pages
On Tue, Apr 16, 2013 at 02:32:50PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become worse if guest uses more memory or vcpus. It is not good for
> scalability.
>
> In this patch, we introduce a faster way to invalid all shadow pages.
> KVM maintains a global mmu invalid generation-number which is stored in
> kvm->arch.mmu_valid_gen and every shadow page stores the current global
> generation-number into sp->mmu_valid_gen when it is created.
>
> When KVM need zap all shadow pages sptes, it just simply increase the
> global generation-number then reload root shadow pages on all vcpus.
> Vcpu will create a new shadow page table according to current kvm's
> generation-number. It ensures the old pages are not used any more.
>
> The invalid-gen pages (sp->mmu_valid_gen != kvm->arch.mmu_valid_gen)
> are keeped in mmu-cache until page allocator reclaims page.
>
> If the invalidation is due to memslot changed, its rmap amd lpage-info
> will be freed soon, in order to avoiding use invalid memory, we unmap
> all sptes on its rmap and always reset the large-info all memslots so
> that rmap and lpage info can be safely freed.
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h |2 +
> arch/x86/kvm/mmu.c | 85 +-
> arch/x86/kvm/mmu.h |4 ++
> arch/x86/kvm/x86.c |6 +++
> 4 files changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 1ad9a34..6f8ee18 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -223,6 +223,7 @@ struct kvm_mmu_page {
> int root_count; /* Currently serving as active root */
> unsigned int unsync_children;
> unsigned long parent_ptes; /* Reverse mapping for parent_pte */
> + unsigned long mmu_valid_gen;
> DECLARE_BITMAP(unsync_child_bitmap, 512);
>
> #ifdef CONFIG_X86_32
> @@ -531,6 +532,7 @@ struct kvm_arch {
> unsigned int n_requested_mmu_pages;
> unsigned int n_max_mmu_pages;
> unsigned int indirect_shadow_pages;
> + unsigned long mmu_valid_gen;
> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
> /*
>* Hash table of struct kvm_mmu_page.
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 9ac584f..12129b7 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -1732,6 +1732,11 @@ static struct rmap_operations invalid_rmap_ops = {
> .rmap_unmap = kvm_unmap_invalid_rmapp
> };
>
> +static void init_invalid_memslot_rmap_ops(struct kvm_memory_slot *slot)
> +{
> + slot->arch.ops = _rmap_ops;
> +}
> +
> typedef void (*handle_rmap_fun)(unsigned long *rmapp, void *data);
> static void walk_memslot_rmap_nolock(struct kvm_memory_slot *slot,
>handle_rmap_fun fun, void *data)
> @@ -1812,6 +1817,65 @@ void free_meslot_rmap_desc_nolock(struct
> kvm_memory_slot *slot)
> walk_memslot_rmap_nolock(slot, free_rmap_desc_nolock, NULL);
> }
>
> +/*
> + * Fast invalid all shadow pages belong to @slot.
> + *
> + * @slot != NULL means the invalidation is caused the memslot specified
> + * by @slot is being deleted, in this case, we should ensure that rmap
> + * and lpage-info of the @slot can not be used after calling the function.
> + * Specially, if @slot is INVALID_ALL_SLOTS, all slots will be deleted
> + * soon, it always happens when kvm is being destroyed.
> + *
> + * @slot == NULL means the invalidation due to other reasons, we need
> + * not care rmap and lpage-info since they are still valid after calling
> + * the function.
> + */
> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
> +struct kvm_memory_slot *slot)
> +{
> + struct kvm_memory_slot *each_slot;
> +
> + spin_lock(>mmu_lock);
> + kvm->arch.mmu_valid_gen++;
> +
> + if (slot == INVALID_ALL_SLOTS)
> + kvm_for_each_memslot(each_slot, kvm_memslots(kvm))
> + init_invalid_memslot_rmap_ops(each_slot);
> + else if (slot)
> + init_invalid_memslot_rmap_ops(slot);
> +
> + /*
> + * All shadow paes are invalid, reset the large page info,
> + * then we can safely desotry the memslot, it is also good
> + * for large page used.
> + */
> + kvm_clear_all_lpage_info(kvm);
> +
> + /*
> + * Notify all vcpus to reload its shadow page table
> + * and flush TLB. Then all vcpus will switch to new
> + * shadow page table with the new mmu_valid_gen.
> + *
> + * Note: we should do this under the protection of
> + * mmu-lock, otherwise, vcpu would purge shadow page
> + * but miss tlb flush.
> + */
> +
Re: [PATCH v3 15/15] KVM: MMU: replace kvm_zap_all with kvm_mmu_invalid_all_pages
On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote: > Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and > rename kvm_zap_all to kvm_free_all which is used to free all > memmory used by kvm mmu when vm is being destroyed, at this time, > no vcpu exists and mmu-notify has been unregistered, so we can > free the shadow pages out of mmu-lock Since there is no contention for mmu-lock its also not a problem to grab the lock right? Automated verification of locking/srcu might complain. -- 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 RFC v2] regulator: core: Add regulator_map_voltage_ascend() API
A lot of regulator hardware has ascendant voltage list.
This patch adds regulator_map_voltage_ascend() and export it.
Drivers that have ascendant voltage list can use this as their map_voltage()
operation, this is more efficient than default regulator_map_voltage_iterate()
function.
Signed-off-by: Axel Lin
---
v2:
Since the voltage list is in ascendant order, and we iterate the list from the
smallest voltage. So it is safe to break out if the voltage is greater than
max_uV.
drivers/regulator/core.c | 31 +++
include/linux/regulator/driver.h |2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 23df943..944d172 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2265,6 +2265,37 @@ int regulator_map_voltage_iterate(struct regulator_dev
*rdev,
EXPORT_SYMBOL_GPL(regulator_map_voltage_iterate);
/**
+ * regulator_map_voltage_ascend - map_voltage() for ascendant voltage list
+ *
+ * @rdev: Regulator to operate on
+ * @min_uV: Lower bound for voltage
+ * @max_uV: Upper bound for voltage
+ *
+ * Drivers that have ascendant voltage list can use this as their
+ * map_voltage() operation.
+ */
+int regulator_map_voltage_ascend(struct regulator_dev *rdev,
+int min_uV, int max_uV)
+{
+ int i, ret;
+
+ for (i = 0; i < rdev->desc->n_voltages; i++) {
+ ret = rdev->desc->ops->list_voltage(rdev, i);
+ if (ret < 0)
+ continue;
+
+ if (ret > max_uV)
+ break;
+
+ if (ret >= min_uV && ret <= max_uV)
+ return i;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regulator_map_voltage_ascend);
+
+/**
* regulator_map_voltage_linear - map_voltage() for simple linear mappings
*
* @rdev: Regulator to operate on
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 5e2d13d..6700cc9 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -332,6 +332,8 @@ int regulator_map_voltage_linear(struct regulator_dev *rdev,
int min_uV, int max_uV);
int regulator_map_voltage_iterate(struct regulator_dev *rdev,
int min_uV, int max_uV);
+int regulator_map_voltage_ascend(struct regulator_dev *rdev,
+ int min_uV, int max_uV);
int regulator_get_voltage_sel_regmap(struct regulator_dev *rdev);
int regulator_set_voltage_sel_regmap(struct regulator_dev *rdev, unsigned sel);
int regulator_is_enabled_regmap(struct regulator_dev *rdev);
--
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: NumaTOP 1.0 launched
Hi, https://01.org/numatop/ is slightly faster to access. Or please access https://github.com/01org/numatop to get the source directly. Thanks Jin Yao -Original Message- From: Jin, Yao Sent: Wednesday, April 17, 2013 10:30 AM To: 'l...@lwn.net'; 'linux-kernel@vger.kernel.org'; 'linux-perf-us...@vger.kernel.org' Subject: NumaTOP 1.0 launched We are pleased to announce today that the NumaTOP project has been added to 01.org. Performance analysis engineers know that NUMA can seriously impact performance and that NUMA performance analysis can be challenging. We've realized that currently there isn't an easy-to-use tool that lets us easily observe whether NUMA-related issues exist and, if so, where the NUMA bottleneck(s) reside. It can be quite challenging, especially in complex server environments. We decided to create a tool that automatically performs the typical steps in NUMA analysis and provides a good starting point to dive in and fix NUMA-related bottlenecks. That's NumaTOP! NumaTOP is an observation tool for runtime memory locality characterization and analysis of processes and threads running on a NUMA system. It helps the user characterize the NUMA behavior of processes and threads and identify where the NUMA-related performance bottlenecks reside. It uses Intel performance counter sampling technologies and associates the performance data with system runtime information to provide real-time analysis for production systems. NumaTOP is a GUI tool. It can run on Linux kernel 3.8 with a perf load latency patch today. That patch is planned to be integrated into kernel 3.9 or a later release. To learn more about NumaTOP, visit: http://01.org/numatop/ Best Regards Jin Yao -- 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 RFC] regulator: core: Add regulator_map_voltage_ascend() API
A lot of regulator hardware has ascendant voltage list.
This patch adds regulator_map_voltage_ascend() and exports it.
Drivers that have ascendant voltage list can use this as their map_voltage()
operation, this is more efficient than default regulator_map_voltage_iterate()
function.
Signed-off-by: Axel Lin
---
drivers/regulator/core.c | 28
include/linux/regulator/driver.h |2 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 23df943..fde1d47 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2265,6 +2265,34 @@ int regulator_map_voltage_iterate(struct regulator_dev
*rdev,
EXPORT_SYMBOL_GPL(regulator_map_voltage_iterate);
/**
+ * regulator_map_voltage_ascend - map_voltage() for ascendant voltage list
+ *
+ * @rdev: Regulator to operate on
+ * @min_uV: Lower bound for voltage
+ * @max_uV: Upper bound for voltage
+ *
+ * Drivers that have ascendant voltage list can use this as their
+ * map_voltage() operation.
+ */
+int regulator_map_voltage_ascend(struct regulator_dev *rdev,
+int min_uV, int max_uV)
+{
+ int i, ret;
+
+ for (i = 0; i < rdev->desc->n_voltages; i++) {
+ ret = rdev->desc->ops->list_voltage(rdev, i);
+ if (ret < 0)
+ continue;
+
+ if (ret >= min_uV && ret <= max_uV)
+ return i;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regulator_map_voltage_ascend);
+
+/**
* regulator_map_voltage_linear - map_voltage() for simple linear mappings
*
* @rdev: Regulator to operate on
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 5e2d13d..6700cc9 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -332,6 +332,8 @@ int regulator_map_voltage_linear(struct regulator_dev *rdev,
int min_uV, int max_uV);
int regulator_map_voltage_iterate(struct regulator_dev *rdev,
int min_uV, int max_uV);
+int regulator_map_voltage_ascend(struct regulator_dev *rdev,
+ int min_uV, int max_uV);
int regulator_get_voltage_sel_regmap(struct regulator_dev *rdev);
int regulator_set_voltage_sel_regmap(struct regulator_dev *rdev, unsigned sel);
int regulator_is_enabled_regmap(struct regulator_dev *rdev);
--
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 5/5] Make reboot_cpuid a kernel parameter.
On Wed, Apr 17, 2013 at 08:25:39PM -0500, Robin Holt wrote:
> On Wed, Apr 17, 2013 at 05:39:33PM -0700, H. Peter Anvin wrote:
> > On 04/17/2013 05:17 PM, Robin Holt wrote:
> > >
> > > There are 4 items being parsed out of reboot= for x86:
> > > - reboot_modew[arm] | c[old]
> > > - reboot_cpu s[mp]
> > > - reboot_typeb[ios] | a[cpi] | k[bd] | t[riple] | e[fi] |
> > > p[ci]
> > > - reboot_force f[orce]
> > >
> > > This seems like a lot to push into the generic kernel just to make it
> > > appear consistent when there will be no real cross arch consistency.
> > >
> > > Contrast that with:
> > > 1) New kernel parameter (reboot_cpu) which is clear and concise, uses
> > > standard
> > >parsing methods.
> > > 2) Backwards compatibility in that a user with an existing (broken)
> > > reboot=s32
> > >on the command line will set reboot_cpu unless both were specified, in
> > > which
> > >case reboot_cpu takes precedence.
> > >
> > > What is so fundamentally wrong with that? It accomplishes exactly what
> > > you had asked for in that existing users are not broken. We are
> > > introducing
> > > a new functionality in the general kernel. Why not introduce a new
> > > parameter
> > > associated with that functionality.
> > >
> >
> > You are confusing implementation with interface. That is what is so
> > fundamentally wrong with that. You really, really don't want to change
> > interface unless the world will end if you don't.
> >
> > As far as why centralize -- the main concern I have is that someone
> > might try to introduce an arch-specific reboot= which is *syntactically*
> > different, which is yet again really awful from a user perspective.
>
> Yes and no. I am saying that the interface is garbage and already
> specified as arch specific. You are asking me to take that garbage
> interface and promote it to a general interface which will force us to
> implement it in a completely crappy way.
>
> Compare that with introducing a new interface which is concise and then
> providing backwards compatibility. Add to that the fact, I don't need
> to pollute the kernel with some poorly done x86 interface and leave that
> cruft for others to clean up.
OK. Here goes:
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4609e81..35af99e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2593,9 +2593,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.
- reboot= [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
- Format: [,[,...]]
- See arch/*/kernel/reboot.c or arch/*/kernel/process.c
+ reboot= [KNL]
+ Format:
+ [w[arm] | c[old]] \
+ [,b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] |
p[ci]] \
+ [,f[orce] \
+ [,] s[mp]
+ Where reboot_mode is one of warm or cold,
+ reboot_type is one of bios, acpi, kbd, triple,
efi, or pci,
+ reboot_force is either force or not specified,
+ and reboot_cpu is s[mp] with being the
+ processor to be used for rebooting.
relax_domain_level=
[KNL, SMP] Set scheduler's default relax_domain_level.
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 76fa1e9..f9e8bf4 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -36,22 +36,11 @@ void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
static const struct desc_ptr no_idt = {};
-static int reboot_mode;
-enum reboot_type reboot_type = BOOT_ACPI;
-int reboot_force;
+extern int reboot_mode;
+extern enum reboot_type reboot_type;
+extern int reboot_force;
-/*
- * This variable is used privately to keep track of whether or not
- * reboot_type is still set to its default value (i.e., reboot= hasn't
- * been set on the command line). This is needed so that we can
- * suppress DMI scanning for reboot quirks. Without it, it's
- * impossible to override a faulty reboot quirk without recompiling.
- */
-static int reboot_default = 1;
-
-#ifdef CONFIG_SMP
-static int reboot_cpu = -1;
-#endif
+extern int reboot_default;
/*
* This is set if we need to go through the 'emergency' path.
@@ -63,78 +52,6 @@ static int reboot_emergency;
/* This is set by the PCI code if either type 1 or type 2 PCI is detected */
bool port_cf9_safe = false;
-/*
- * reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
- * warm Don't set the cold reboot flag
- * cold Set the
Re: mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)
On Wed, Apr 17, 2013 at 6:44 PM, Randy Dunlap wrote: > On 04/17/13 16:03, a...@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to >> >>http://www.ozlabs.org/~akpm/mmotm/ >> > > > I saw this in linux-next a few days ago and forgot to post it. > > When CONFIG_DEBUG_FS is not enabled: just pushed a fix to my drm-next branch. Thanks. Dave. -- 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 v7 0/21] sched: power aware scheduling
On Wed, 2013-04-17 at 17:53 -0400, Len Brown wrote: > On 04/12/2013 12:48 PM, Mike Galbraith wrote: > > On Fri, 2013-04-12 at 18:23 +0200, Borislav Petkov wrote: > >> On Fri, Apr 12, 2013 at 04:46:50PM +0800, Alex Shi wrote: > >>> Thanks a lot for comments, Len! > >> > >> AFAICT, you kinda forgot to answer his most important question: > >> > >>> These numbers suggest that this patch series simultaneously > >>> has a negative impact on performance and energy required > >>> to retire the workload. Why do it? > > > > Hm. When I tested AIM7 compute on a NUMA box, there was a marked > > throughput increase at the low to moderate load end of the test spectrum > > IIRC. Fully repeatable. There were also other benefits unrelated to > > power, ie mitigation of the evil face of select_idle_sibling(). I > > rather liked what I saw during ~big box test-drive. > > > > (just saying there are other aspects besides joules in there) > > Mike, > > Can you re-run your AIM7 measurement with turbo-mode and HT-mode disabled, > and then independently re-enable them? Unfortunately no, because I don't have remote access to buttons. > If you still see the performance benefit, then that proves > that the scheduler hacks are not about tricking into > turbo mode, but something else. Yeah, turbo playing a role in that makes lots of sense. Someone else will have to test that though. It was 100% repeatable, so should be easy to verify. -Mike -- 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: mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)
On 04/17/13 16:03, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > I saw this in linux-next a few days ago and forgot to post it. When CONFIG_DEBUG_FS is not enabled: drivers/gpu/drm/qxl/qxl_ttm.c:568:33: error: 'qxl_mm_dump_table' undeclared (first use in this function) drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function 'drm_debugfs_create_files' [-Werror=implicit-function-declaration] drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration] -- ~Randy -- 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 ceph tree with Linus' tree
Hi Sage,
Today's linux-next merge of the ceph tree got a conflict in
fs/ceph/addr.c between commit 496ad9aa8ef4 ("new helper: file_inode
(file)") from Linus' tree and commit 42f94fe2cf50 ("ceph: revert commit
22cddde104") from the ceph 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 fs/ceph/addr.c
index a60ea97,068d2c8..000
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@@ -1066,29 -1104,10 +1104,10 @@@ static int ceph_write_begin(struct fil
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata)
{
- struct inode *inode = file->f_dentry->d_inode;
+ struct inode *inode = file_inode(file);
- struct ceph_inode_info *ci = ceph_inode(inode);
- struct ceph_file_info *fi = file->private_data;
struct page *page;
pgoff_t index = pos >> PAGE_CACHE_SHIFT;
- int r, want, got = 0;
-
- if (fi->fmode & CEPH_FILE_MODE_LAZY)
- want = CEPH_CAP_FILE_BUFFER | CEPH_CAP_FILE_LAZYIO;
- else
- want = CEPH_CAP_FILE_BUFFER;
-
- dout("write_begin %p %llx.%llx %llu~%u getting caps. i_size %llu\n",
-inode, ceph_vinop(inode), pos, len, inode->i_size);
- r = ceph_get_caps(ci, CEPH_CAP_FILE_WR, want, , pos+len);
- if (r < 0)
- return r;
- dout("write_begin %p %llx.%llx %llu~%u got cap refs on %s\n",
-inode, ceph_vinop(inode), pos, len, ceph_cap_string(got));
- if (!(got & (CEPH_CAP_FILE_BUFFER|CEPH_CAP_FILE_LAZYIO))) {
- ceph_put_cap_refs(ci, got);
- return -EAGAIN;
- }
+ int r;
do {
/* get a page */
@@@ -1124,8 -1134,7 +1134,7 @@@ static int ceph_write_end(struct file *
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata)
{
- struct inode *inode = file->f_dentry->d_inode;
+ struct inode *inode = file_inode(file);
- struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_fs_client *fsc = ceph_inode_to_client(inode);
struct ceph_mds_client *mdsc = fsc->mdsc;
unsigned from = pos & (PAGE_CACHE_SIZE - 1);
pgpTHAM5SDbV9.pgp
Description: PGP signature
Re: [PATCH -v5 5/5] Make reboot_cpuid a kernel parameter.
On Wed, Apr 17, 2013 at 05:39:33PM -0700, H. Peter Anvin wrote: > On 04/17/2013 05:17 PM, Robin Holt wrote: > > > > There are 4 items being parsed out of reboot= for x86: > > - reboot_mode w[arm] | c[old] > > - reboot_cpu s[mp] > > - reboot_type b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | > > p[ci] > > - reboot_force f[orce] > > > > This seems like a lot to push into the generic kernel just to make it > > appear consistent when there will be no real cross arch consistency. > > > > Contrast that with: > > 1) New kernel parameter (reboot_cpu) which is clear and concise, uses > > standard > >parsing methods. > > 2) Backwards compatibility in that a user with an existing (broken) > > reboot=s32 > >on the command line will set reboot_cpu unless both were specified, in > > which > >case reboot_cpu takes precedence. > > > > What is so fundamentally wrong with that? It accomplishes exactly what > > you had asked for in that existing users are not broken. We are introducing > > a new functionality in the general kernel. Why not introduce a new > > parameter > > associated with that functionality. > > > > You are confusing implementation with interface. That is what is so > fundamentally wrong with that. You really, really don't want to change > interface unless the world will end if you don't. > > As far as why centralize -- the main concern I have is that someone > might try to introduce an arch-specific reboot= which is *syntactically* > different, which is yet again really awful from a user perspective. Yes and no. I am saying that the interface is garbage and already specified as arch specific. You are asking me to take that garbage interface and promote it to a general interface which will force us to implement it in a completely crappy way. Compare that with introducing a new interface which is concise and then providing backwards compatibility. Add to that the fact, I don't need to pollute the kernel with some poorly done x86 interface and leave that cruft for others to clean up. Thanks, Robin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kernel: audit_tree: resource management: need put_tree and goto Err when failure occures
On 2013年04月18日 04:07, Andrew Morton wrote: > On Wed, 17 Apr 2013 12:04:02 +0800 Chen Gang wrote: > >> > since "normally audit_add_tree_rule() will free it on failure", >> > need free it completely, when failure occures. >> > >> > need additional put_tree before return, since get_tree was called. >> > always need goto error processing area for list_del_init. > Isn't that get_tree() in audit_add_tree_rule() simply unneeded? In > other words, is this patch correct: > excuse me: I am not quite familiar with it, and also have to do another things. so I have to spend additional time resource to make sure about it. is it ok ? I should make sure about it within this week (2013-04-21) I should finish related test (if need), within next week (2013-4-28) if have additional suggestions or completions, please reply. (if no reply, I will follow the time point above) thanks. gchen. > --- a/kernel/audit_tree.c~a > +++ a/kernel/audit_tree.c > @@ -682,7 +682,6 @@ int audit_add_tree_rule(struct audit_kru > goto Err; > } > > - get_tree(tree); > err = iterate_mounts(tag_mount, tree, mnt); > drop_collected_mounts(mnt); > > @@ -703,7 +702,6 @@ int audit_add_tree_rule(struct audit_kru > return -ENOENT; > } > rule->tree = tree; > - put_tree(tree); > > return 0; > Err: > _ > > > -- > 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/ > -- Chen Gang Flying Transformer -- 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] KVM: x86: Don't sending posted interrupt if not config CONFIG_SMP
From: Yang Zhang If not config smp, posted interrupt logic will not work. So we should not send posted interrupt and let vcpu to pick the pending interrupt before vmentry. Without this patch, the build fails when CONFIG_SMP is disabled. Thanks Randy to report this issue. Reported-by: Randy Dunlap Signed-off-by: Yang Zhang Acked-by: Randy Dunlap --- arch/x86/kvm/vmx.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 52b21da..d5c6b95 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3946,10 +3946,12 @@ static void vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu, int vector) r = pi_test_and_set_on(>pi_desc); kvm_make_request(KVM_REQ_EVENT, vcpu); +#ifdef CONFIG_SMP if (!r && (vcpu->mode == IN_GUEST_MODE)) apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), POSTED_INTR_VECTOR); else +#endif kvm_vcpu_kick(vcpu); } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: fix memory_hotplug.c printk format warning
From: Randy Dunlap
PFN_PHYS() is a phys_addr_t, which can be u32 or u64.
Fix the build warning when phys_addr_t is u32.
mm/memory_hotplug.c: warning: format '%llx' expects argument of type 'long long
unsigned int', but argument 2 has type 'unsigned int' [-Wformat]: => 1685:3
mm/memory_hotplug.c: warning: format '%llx' expects argument of type 'long long
unsigned int', but argument 3 has type 'unsigned int' [-Wformat]: => 1685:3
Signed-off-by: Randy Dunlap
Reported-by: Geert Uytterhoeven
---
mm/memory_hotplug.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
I guess this modern "%pa" is preferred over casting to (u64),
but just casting seems a simpler fix to me. I.e.:
if (unlikely(ret))
pr_warn("removing memory fails, because memory "
"[%#010llx-%#010llx] is onlined\n",
- PFN_PHYS(section_nr_to_pfn(mem->start_section_nr)),
- PFN_PHYS(section_nr_to_pfn(mem->end_section_nr + 1))-1);
+ (u64)PFN_PHYS(section_nr_to_pfn(mem->start_section_nr)),
+ (u64)PFN_PHYS(section_nr_to_pfn(
+ mem->end_section_nr + 1))-1);
return ret;
}
--- lnx-39-rc7.orig/mm/memory_hotplug.c
+++ lnx-39-rc7/mm/memory_hotplug.c
@@ -1681,11 +1681,15 @@ static int is_memblock_offlined_cb(struc
{
int ret = !is_memblock_offlined(mem);
- if (unlikely(ret))
+ if (unlikely(ret)) {
+ phys_addr_t beginpa, endpa;
+
+ beginpa = PFN_PHYS(section_nr_to_pfn(mem->start_section_nr));
+ endpa = PFN_PHYS(section_nr_to_pfn(mem->end_section_nr + 1))-1;
pr_warn("removing memory fails, because memory "
- "[%#010llx-%#010llx] is onlined\n",
- PFN_PHYS(section_nr_to_pfn(mem->start_section_nr)),
- PFN_PHYS(section_nr_to_pfn(mem->end_section_nr + 1))-1);
+ "[%pa-%pa] is onlined\n",
+ , );
+ }
return ret;
}
--
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, kvm: fix build failure with CONFIG_SMP disabled
Randy Dunlap wrote on 2013-04-18: > On 04/17/13 17:35, Zhang, Yang Z wrote: >> David Rientjes wrote on 2013-04-18: >>> On Wed, 17 Apr 2013, Randy Dunlap wrote: >>> On 04/17/13 16:12, David Rientjes wrote: > The build fails when CONFIG_SMP is disabled: > > arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': > arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in > this function) > > Fix it by including the necessary header. Sorry, i386 build still fails with the same error message plus this one: ERROR: "apic" [arch/x86/kvm/kvm-intel.ko] undefined! >>> >>> Ahh, that's because you don't have CONFIG_X86_LOCAL_APIC as you already >>> mentioned. So it looks like this error can manifest in two different ways >>> and we got different reports. >>> >>> This failure came from "KVM: VMX: Add the deliver posted interrupt >>> algorithm", so adding Yang to the cc to specify the dependency this has on >>> apic and how it can be protected without CONFIG_X86_LOCAL_APIC on i386. >> How about the follow patch? >> >> commit a49dd819f502c1029c5a857e87201ef25ec06ce6 >> Author: Yang Zhang >> Date: Wed Apr 17 05:34:07 2013 -0400 >> >> KVM: x86: Don't sending posted interrupt if not config CONFIG_SMP >> >> In UP, posted interrupt logic will not work. So we should not send >> posted interrupt and let vcpu to pick the pending interrupt before >> vmentry. >> >> Signed-off-by: Yang Zhang > > Missing Reported-by: and the patch does not apply cleanly (looks like > lots of spaces instead of tabs in it)... but it does build now after > massaging the patch. Thanks. Just copy it to you for a quick testing. I will resend a formal patch. > Thanks. > > Acked-by: Randy Dunlap > > >> >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index >> 52b21da..d5c6b95 100644 --- a/arch/x86/kvm/vmx.c +++ >> b/arch/x86/kvm/vmx.c @@ -3946,10 +3946,12 @@ static void >> vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu, int vector) >> >> r = pi_test_and_set_on(>pi_desc); >> kvm_make_request(KVM_REQ_EVENT, vcpu); +#ifdef CONFIG_SMP if >> (!r && (vcpu->mode == IN_GUEST_MODE)) >> apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), >> POSTED_INTR_VECTOR); >> else >> +#endif >> kvm_vcpu_kick(vcpu); >> } >> Best regards, >> Yang >> >> > > > -- > ~Randy > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Best regards, Yang -- 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, kvm: fix build failure with CONFIG_SMP disabled
On 04/17/13 17:35, Zhang, Yang Z wrote: > David Rientjes wrote on 2013-04-18: >> On Wed, 17 Apr 2013, Randy Dunlap wrote: >> >>> On 04/17/13 16:12, David Rientjes wrote: The build fails when CONFIG_SMP is disabled: arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in this function) Fix it by including the necessary header. >>> >>> Sorry, i386 build still fails with the same error message plus this one: >>> >>> ERROR: "apic" [arch/x86/kvm/kvm-intel.ko] undefined! >>> >> >> Ahh, that's because you don't have CONFIG_X86_LOCAL_APIC as you already >> mentioned. So it looks like this error can manifest in two different ways >> and we got different reports. >> >> This failure came from "KVM: VMX: Add the deliver posted interrupt >> algorithm", so adding Yang to the cc to specify the dependency this has on >> apic and how it can be protected without CONFIG_X86_LOCAL_APIC on i386. > How about the follow patch? > > commit a49dd819f502c1029c5a857e87201ef25ec06ce6 > Author: Yang Zhang > Date: Wed Apr 17 05:34:07 2013 -0400 > > KVM: x86: Don't sending posted interrupt if not config CONFIG_SMP > > In UP, posted interrupt logic will not work. So we should not send > posted interrupt and let vcpu to pick the pending interrupt before > vmentry. > > Signed-off-by: Yang Zhang Missing Reported-by: and the patch does not apply cleanly (looks like lots of spaces instead of tabs in it)... but it does build now after massaging the patch. Thanks. Acked-by: Randy Dunlap > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 52b21da..d5c6b95 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -3946,10 +3946,12 @@ static void vmx_deliver_posted_interrupt(struct > kvm_vcpu *vcpu, int vector) > > r = pi_test_and_set_on(>pi_desc); > kvm_make_request(KVM_REQ_EVENT, vcpu); > +#ifdef CONFIG_SMP > if (!r && (vcpu->mode == IN_GUEST_MODE)) > apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), > POSTED_INTR_VECTOR); > else > +#endif > kvm_vcpu_kick(vcpu); > } > > Best regards, > Yang > > -- ~Randy -- 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 V4] edac: Handle EDAC ECC errors for Family 16h
On 04/17/2013 04:20 PM, Borislav Petkov wrote:
[ trim CC-list ]
On Wed, Apr 17, 2013 at 02:57:13PM -0500, Aravind Gopalakrishnan wrote:
Add code to handle ECC decoding for fam16h. Support exists for
previous families already, so code has been reused werever applicable
and some code has been added to handle fam16h specific operations.
The patch was tested on Fam16h with ECC turned on
using the mce_amd_inj facility and works fine.
update: corrections to code from previous versions involve few cosmetic
changes, reusing f10_read_dct_pci_cfg and basing off tip/master
Signed-off-by: Aravind Gopalakrishnan
Ok,
looks almost good, just a couple of cleanups. I also replaced the
lenghty comments with a reference to the BKDG. Please test the below
version and let me know,
Thanks.
--
From: Aravind Gopalakrishnan
Date: Wed, 17 Apr 2013 14:57:13 -0500
Subject: [PATCH] amd64_edac: Add Family 16h support
Add code to handle DRAM ECC errors decoding for Fam16h.
Tested on Fam16h with ECC turned on using the mce_amd_inj facility and
works fine.
Signed-off-by: Aravind Gopalakrishnan
[ Boris: cleanups and clarifications ]
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/amd_nb.c | 3 ++-
drivers/edac/amd64_edac.c | 65 ++-
drivers/edac/amd64_edac.h | 4 ++-
include/linux/pci_ids.h | 2 ++
4 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index 3684129be947..3048ded1b598 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -20,12 +20,14 @@ const struct pci_device_id amd_nb_misc_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{}
};
EXPORT_SYMBOL(amd_nb_misc_ids);
static const struct pci_device_id amd_nb_link_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
{}
};
For some reason, this hunk does not apply cleanly..
I tried this: (moving the line)
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
{}
};
and this seems to work..
Otherwise, I tested the patch and it works.
@@ -81,7 +83,6 @@ int amd_cache_northbridges(void)
next_northbridge(link, amd_nb_link_ids);
}
- /* some CPU families (e.g. family 0x11) do not support GART */
if (boot_cpu_data.x86 == 0xf || boot_cpu_data.x86 == 0x10 ||
boot_cpu_data.x86 == 0x15)
amd_northbridges.flags |= AMD_NB_GART;
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index e1d13c463c90..8b6a0343c220 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -98,6 +98,7 @@ int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int
offset,
*
* F15h: we select which DCT we access using F1x10C[DctCfgSel]
*
+ * F16h: has only 1 DCT
*/
static int k8_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
const char *func)
@@ -340,6 +341,27 @@ static void get_cs_base_and_mask(struct amd64_pvt *pvt,
int csrow, u8 dct,
base_bits = GENMASK(21, 31) | GENMASK(9, 15);
mask_bits = GENMASK(21, 29) | GENMASK(9, 15);
addr_shift = 4;
+
+ /*
+ * F16h needs two addr_shift values: 8 for high and 6 for low
+ * (cf. F16h BKDG).
+ */
+ } else if (boot_cpu_data.x86 == 0x16) {
+ csbase = pvt->csels[dct].csbases[csrow];
+ csmask = pvt->csels[dct].csmasks[csrow >> 1];
+
+ *base = (csbase & GENMASK(5, 15)) << 6;
+ *base |= (csbase & GENMASK(19, 30)) << 8;
+
+ *mask = ~0ULL;
+ /* poke holes for the csmask */
+ *mask &= ~((GENMASK(5, 15) << 6) |
+ (GENMASK(19, 30) << 8));
+
+ *mask |= (csmask & GENMASK(5, 15)) << 6;
+ *mask |= (csmask & GENMASK(19, 30)) << 8;
+
+ return;
} else {
csbase = pvt->csels[dct].csbases[csrow];
csmask = pvt->csels[dct].csmasks[csrow >> 1];
@@ -1150,6 +1172,21 @@ static int f15_dbam_to_chip_select(struct amd64_pvt
*pvt, u8 dct,
return ddr3_cs_size(cs_mode, false);
}
+/*
+ * F16h has only limited cs_modes
+ */
+static int f16_dbam_to_chip_select(struct amd64_pvt *pvt, u8 dct,
+
Re: [PATCH -v5 5/5] Make reboot_cpuid a kernel parameter.
On 04/17/2013 05:17 PM, Robin Holt wrote: > > There are 4 items being parsed out of reboot= for x86: > - reboot_modew[arm] | c[old] > - reboot_cpu s[mp] > - reboot_typeb[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | > p[ci] > - reboot_force f[orce] > > This seems like a lot to push into the generic kernel just to make it > appear consistent when there will be no real cross arch consistency. > > Contrast that with: > 1) New kernel parameter (reboot_cpu) which is clear and concise, uses standard >parsing methods. > 2) Backwards compatibility in that a user with an existing (broken) reboot=s32 >on the command line will set reboot_cpu unless both were specified, in > which >case reboot_cpu takes precedence. > > What is so fundamentally wrong with that? It accomplishes exactly what > you had asked for in that existing users are not broken. We are introducing > a new functionality in the general kernel. Why not introduce a new parameter > associated with that functionality. > You are confusing implementation with interface. That is what is so fundamentally wrong with that. You really, really don't want to change interface unless the world will end if you don't. As far as why centralize -- the main concern I have is that someone might try to introduce an arch-specific reboot= which is *syntactically* different, which is yet again really awful from a user perspective. -hpa -- 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/
Re: [RFC Patch 0/2] mm: Add parameters to make kernel behavior at memory error on dirty cache selectable
Hi Naoya,
On 04/17/2013 10:55 PM, Naoya Horiguchi wrote:
> On Wed, Apr 17, 2013 at 03:14:36PM +0800, Simon Jeons wrote:
>> Hi Naoya,
>> On 04/11/2013 03:11 PM, Naoya Horiguchi wrote:
>>> Hi Tanino-san,
>>>
>>> On Thu, Apr 11, 2013 at 12:26:19PM +0900, Mitsuhiro Tanino wrote:
>>> ...
Solution
-
The patch proposes a new sysctl interface, vm.memory_failure_dirty_panic,
in order to prevent data corruption comes from data lost problem.
Also this patch displays information of affected file such as device name,
inode number, file offset and file type if the file is mapped on a memory
and the page is dirty cache.
When SRAO machine check occurs on a dirty page cache, corresponding
data cannot be recovered any more. Therefore, the patch proposes a kernel
option to keep a system running or force system panic in order
to avoid further trouble such as data corruption problem of application.
System administrator can select an error action using this option
according to characteristics of target system.
>>> Can we do this in userspace?
>>> mcelog can trigger scripts when a MCE which matches the user-configurable
>>> conditions happens, so I think that we can trigger a kernel panic by
>>> chekcing kernel messages from the triggered script.
>>> For that purpose, I recently fixed the dirty/clean messaging in commit
>>> ff604cf6d4 "mm: hwpoison: fix action_result() to print out dirty/clean".
>> In your commit ff604cf6d4, you mentioned that "because when we check
>> PageDirty in action_result() it was cleared after page isolation even if
>> it's dirty before error handling." Could you point out where page
>> isolation and clear PageDirty? I don't think is isolate_lru_pages.
> Here is the result of ftracing of memory_failure().
> cancel_dirty_page() is called inside me_pagecache_dirty(), that's it.
Cool! What's the option you used in this ftrace.
>
>mceinj.sh-7662 [000] 154195.857024: funcgraph_entry:
> |memory_failure() {
>mceinj.sh-7662 [000] 154195.857024: funcgraph_entry:0.283 us
> | PageHuge();
>mceinj.sh-7662 [000] 154195.857025: funcgraph_entry:0.321 us
> | _cond_resched();
>mceinj.sh-7662 [000] 154195.857025: funcgraph_entry:0.348 us
> | hwpoison_filter();
>mceinj.sh-7662 [000] 154195.857026: funcgraph_entry:0.323 us
> | PageHuge();
>mceinj.sh-7662 [000] 154195.857027: funcgraph_entry:0.264 us
> | PageHuge();
>mceinj.sh-7662 [000] 154195.857027: funcgraph_entry:
> | kmem_cache_alloc_trace() {
>mceinj.sh-7662 [000] 154195.857028: funcgraph_entry:0.254 us
> |_cond_resched();
>mceinj.sh-7662 [000] 154195.857028: funcgraph_exit: 0.905 us
> | }
>mceinj.sh-7662 [000] 154195.857029: funcgraph_entry:0.308 us
> | _read_lock();
>mceinj.sh-7662 [000] 154195.857029: funcgraph_entry:0.326 us
> | _spin_lock();
>mceinj.sh-7662 [000] 154195.857057: funcgraph_entry:
> | kfree() {
>mceinj.sh-7662 [000] 154195.857057: funcgraph_entry:0.252 us
> |__phys_addr();
>mceinj.sh-7662 [000] 154195.857058: funcgraph_exit: 1.000 us
> | }
>mceinj.sh-7662 [000] 154195.857058: funcgraph_entry:
> | try_to_unmap() {
>mceinj.sh-7662 [000] 154195.857058: funcgraph_entry:
> |try_to_unmap_file() {
>mceinj.sh-7662 [000] 154195.857059: funcgraph_entry:0.430 us
> | _spin_lock();
>mceinj.sh-7662 [000] 154195.857060: funcgraph_entry:0.719 us
> | vma_prio_tree_next();
>mceinj.sh-7662 [000] 154195.857061: funcgraph_entry:
> | try_to_unmap_one() {
>mceinj.sh-7662 [000] 154195.857061: funcgraph_entry:
> |page_check_address() {
>mceinj.sh-7662 [000] 154195.857061: funcgraph_entry:0.256 us
> | PageHuge();
>mceinj.sh-7662 [000] 154195.857062: funcgraph_entry:0.419 us
> | _spin_lock();
>mceinj.sh-7662 [000] 154195.857063: funcgraph_exit: 1.812 us
> |}
>mceinj.sh-7662 [000] 154195.857063: funcgraph_entry:
> |flush_tlb_page() {
>mceinj.sh-7662 [000] 154195.857064: funcgraph_entry:
> | native_flush_tlb_others() {
>mceinj.sh-7662 [000] 154195.857064: funcgraph_entry:0.286 us
> |is_uv_system();
>
RE: [patch] x86, kvm: fix build failure with CONFIG_SMP disabled
David Rientjes wrote on 2013-04-18: > On Wed, 17 Apr 2013, Randy Dunlap wrote: > >> On 04/17/13 16:12, David Rientjes wrote: >>> The build fails when CONFIG_SMP is disabled: >>> >>> arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': >>> arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in >>> this function) >>> >>> Fix it by including the necessary header. >> >> Sorry, i386 build still fails with the same error message plus this one: >> >> ERROR: "apic" [arch/x86/kvm/kvm-intel.ko] undefined! >> > > Ahh, that's because you don't have CONFIG_X86_LOCAL_APIC as you already > mentioned. So it looks like this error can manifest in two different ways > and we got different reports. > > This failure came from "KVM: VMX: Add the deliver posted interrupt > algorithm", so adding Yang to the cc to specify the dependency this has on > apic and how it can be protected without CONFIG_X86_LOCAL_APIC on i386. How about the follow patch? commit a49dd819f502c1029c5a857e87201ef25ec06ce6 Author: Yang Zhang Date: Wed Apr 17 05:34:07 2013 -0400 KVM: x86: Don't sending posted interrupt if not config CONFIG_SMP In UP, posted interrupt logic will not work. So we should not send posted interrupt and let vcpu to pick the pending interrupt before vmentry. Signed-off-by: Yang Zhang diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 52b21da..d5c6b95 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3946,10 +3946,12 @@ static void vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu, int vector) r = pi_test_and_set_on(>pi_desc); kvm_make_request(KVM_REQ_EVENT, vcpu); +#ifdef CONFIG_SMP if (!r && (vcpu->mode == IN_GUEST_MODE)) apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), POSTED_INTR_VECTOR); else +#endif kvm_vcpu_kick(vcpu); } Best regards, Yang -- 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] ARM: sched_clock: Add more notrace to prevent recursion
On 03/26/13 10:35, Stephen Boyd wrote:
> On 03/21/13 10:49, Stephen Boyd wrote:
>> On 03/14/13 17:08, Stephen Boyd wrote:
>>> cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
>>> is called by cyc_to_sched_clock(). I suspect that some compilers
>>> inline both of these functions into sched_clock() and so we've
>>> been getting away without having a notrace marking. It seems that
>>> my compiler isn't inlining cyc_to_sched_clock() though, so I'm
>>> hitting a recursion bug when I enable the function graph tracer,
>>> causing my system to crash. Marking these functions notrace fixes
>>> it. Technically cyc_to_ns() doesn't need the notrace because it's
>>> already marked inline, but let's just add it so that if we ever
>>> remove inline from that function it doesn't blow up.
>> Anyone else seeing this problem?
> Russell, should I put this into the patch tracker?
I'll throw this into the patch tracker tomorrow if nobody complains.
>>> Signed-off-by: Stephen Boyd
>>> ---
>>> arch/arm/kernel/sched_clock.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
>>> index bd6f56b..59d2adb 100644
>>> --- a/arch/arm/kernel/sched_clock.c
>>> +++ b/arch/arm/kernel/sched_clock.c
>>> @@ -45,12 +45,12 @@ static u32 notrace jiffy_sched_clock_read(void)
>>>
>>> static u32 __read_mostly (*read_sched_clock)(void) =
>>> jiffy_sched_clock_read;
>>>
>>> -static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>>> +static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
>>> {
>>> return (cyc * mult) >> shift;
>>> }
>>>
>>> -static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
>>> +static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
>>> {
>>> u64 epoch_ns;
>>> u32 epoch_cyc;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] slab: Remove unnecessary __builtin_constant_p()
On Thu, 18 Apr 2013, Will Huck wrote: > In normal case, builtin_constant_p() is used for what? > http://gcc.gnu.org/onlinedocs/ -- 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 5/5] Make reboot_cpuid a kernel parameter.
Better that than someone creating a completely different syntax. Robin Holt wrote: >On Wed, Apr 17, 2013 at 03:15:33PM -0500, Robin Holt wrote: >> On Wed, Apr 17, 2013 at 12:59:57PM -0700, H. Peter Anvin wrote: >> > It is also worth noting that the documentation says reboot=s[mp]# >> > whereas in fact only reboot=s# parse correctly. I consider this to >be a >> > bug. >> > >> > If we centralized the parser, we could take a string like >> > >> > "reboot=bios,smp32,warm" >> > >> > and parse it into: >> > >> > reboot_cpu = 32 >> > reboot_mode = "bw" >> > >> > ... and pass the information in that form to the arch layer. I >don't >> > think we can do more parsing at that in the main kernel. >> >> OK. I will go back to the drawing board again. > >There are 4 items being parsed out of reboot= for x86: > - reboot_mode w[arm] | c[old] > - reboot_cpu s[mp] > - reboot_type b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci] > - reboot_forcef[orce] > >This seems like a lot to push into the generic kernel just to make it >appear consistent when there will be no real cross arch consistency. > > >Contrast that with: >1) New kernel parameter (reboot_cpu) which is clear and concise, uses >standard > parsing methods. >2) Backwards compatibility in that a user with an existing (broken) >reboot=s32 >on the command line will set reboot_cpu unless both were specified, in >which > case reboot_cpu takes precedence. > >What is so fundamentally wrong with that? It accomplishes exactly what >you had asked for in that existing users are not broken. We are >introducing >a new functionality in the general kernel. Why not introduce a new >parameter >associated with that functionality. > >Thanks, >Robin -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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: storage: Add usb_stor_dbg, reduce object size
On Wed, 2013-04-17 at 14:47 -0400, Alan Stern wrote:
> On Wed, 17 Apr 2013, Joe Perches wrote:
[]
> > +int usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
> > +{
> > + struct va_format vaf;
> > + va_list args;
> > + int r;
> > +
> > + va_start(args, fmt);
> > +
> > + if (us && us->pusb_dev) {
> > + r = dev_vprintk_emit(7, >pusb_dev->dev, fmt, args);
>
> Isn't there a symbolic constant you can use instead of "7"?
Nope.
lib/dynamic_debug:__dynamic_dev_dbg() does the same thing.
> > --- a/drivers/usb/storage/scsiglue.c
> > +++ b/drivers/usb/storage/scsiglue.c
>
> > @@ -349,8 +347,6 @@ static int command_abort(struct scsi_cmnd *srb)
[]
> > - US_DEBUGP("%s called\n", __func__);
[]
> > @@ -386,8 +382,6 @@ static int device_reset(struct scsi_cmnd *srb)
[]
> > - US_DEBUGP("%s called\n", __func__);
[]
> > @@ -402,7 +396,6 @@ static int bus_reset(struct scsi_cmnd *srb)
[]
> > - US_DEBUGP("%s called\n", __func__);
> These three functions get called only in unusual circumstances, and for
> debugging we do want to know when they get called. So these statements
> should remain.
I'll put 'em back and resubmit the whole schmear against
what Greg has in his tree now later. I do think that
the function tracer does all that though and more.
Look at Documentation/trace/ftrace.txt
> > --- a/drivers/usb/storage/usb.c
[]
> > @@ -918,7 +902,7 @@ int usb_stor_probe1(struct us_data **pus,
[]
> > - US_DEBUGP("USB Mass Storage device detected\n");
> > + usb_stor_dbg(NULL, "USB Mass Storage device detected\n");
[]
> Even though "us" isn't available here, intf is. This line can be a
> regular dev_dbg(>dev, ...). Or even dev_info(>dev, ...);
> this looks like the sort of thing one sees all the time in kernel logs.
I'll make it dev_info
> > @@ -1075,9 +1058,8 @@ static int storage_probe(struct usb_interface *intf,
[]
> > + usb_stor_dbg(us, "Use Bulk-Only transport with the
> > Transparent SCSI protocol for dynamic id: 0x%04x 0x%04x\n",
> > + id->idVendor, id->idProduct);
> And here "us" hasn't been set yet (it gets set in usb_stor_probe1), so
> it shouldn't be used. This can become another dev_dbg(>dev, ...)
> line.
OK.
--
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 5/5] Make reboot_cpuid a kernel parameter.
On Wed, Apr 17, 2013 at 03:15:33PM -0500, Robin Holt wrote: > On Wed, Apr 17, 2013 at 12:59:57PM -0700, H. Peter Anvin wrote: > > It is also worth noting that the documentation says reboot=s[mp]# > > whereas in fact only reboot=s# parse correctly. I consider this to be a > > bug. > > > > If we centralized the parser, we could take a string like > > > > "reboot=bios,smp32,warm" > > > > and parse it into: > > > > reboot_cpu = 32 > > reboot_mode = "bw" > > > > ... and pass the information in that form to the arch layer. I don't > > think we can do more parsing at that in the main kernel. > > OK. I will go back to the drawing board again. There are 4 items being parsed out of reboot= for x86: - reboot_mode w[arm] | c[old] - reboot_cpu s[mp] - reboot_type b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci] - reboot_force f[orce] This seems like a lot to push into the generic kernel just to make it appear consistent when there will be no real cross arch consistency. Contrast that with: 1) New kernel parameter (reboot_cpu) which is clear and concise, uses standard parsing methods. 2) Backwards compatibility in that a user with an existing (broken) reboot=s32 on the command line will set reboot_cpu unless both were specified, in which case reboot_cpu takes precedence. What is so fundamentally wrong with that? It accomplishes exactly what you had asked for in that existing users are not broken. We are introducing a new functionality in the general kernel. Why not introduce a new parameter associated with that functionality. Thanks, Robin -- 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] slab: Remove unnecessary __builtin_constant_p()
Hi Steven,
On 04/18/2013 03:09 AM, Steven Rostedt wrote:
The slab.c code has a size check macro that checks the size of the
following structs:
struct arraycache_init
struct kmem_list3
The index_of() function that takes the sizeof() of the above two structs
and does an unnecessary __builtin_constant_p() on that. As sizeof() will
always end up being a constant making this always be true. The code is
not incorrect, but it just adds added complexity, and confuses users and
wastes the time of reviewers of the code, who spends time trying to
figure out why the builtin_constant_p() was used.
In normal case, builtin_constant_p() is used for what?
This patch is just a clean up that makes the index_of() code a little
bit less complex.
Signed-off-by: Steven Rostedt
diff --git a/mm/slab.c b/mm/slab.c
index 856e4a1..6047900 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -325,9 +325,7 @@ static void cache_reap(struct work_struct *unused);
static __always_inline int index_of(const size_t size)
{
extern void __bad_size(void);
-
- if (__builtin_constant_p(size)) {
- int i = 0;
+ int i = 0;
#define CACHE(x) \
if (size <=x) \
@@ -336,9 +334,7 @@ static __always_inline int index_of(const size_t size)
i++;
#include
#undef CACHE
- __bad_size();
- } else
- __bad_size();
+ __bad_size();
return 0;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.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/
Re: [PATCH] swap: redirty page if page write fails on swap file
Hi Jerome,
On 04/17/2013 08:11 PM, Jerome Marchand wrote:
Since commit 62c230b, swap_writepage() calls direct_IO on swap files.
However, in that case page isn't redirtied if I/O fails, and is therefore
handled afterwards as if it has been successfully written to the swap
file, leading to memory corruption when the page is eventually swapped
back in.
This patch sets the page dirty when direct_IO() fails. It fixes a memory
If swapfile has related page cache which cached swapfile in memory? It
is not necessary, correct?
corruption that happened while using swap-over-NFS.
Signed-off-by: Jerome Marchand
---
mm/page_io.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index 78eee32..04ca00d 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -222,6 +222,8 @@ int swap_writepage(struct page *page, struct
writeback_control *wbc)
if (ret == PAGE_SIZE) {
count_vm_event(PSWPOUT);
ret = 0;
+ } else {
+ set_page_dirty(page);
}
return ret;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.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/
Re: [patch] x86, kvm: fix build failure with CONFIG_SMP disabled
On Wed, 17 Apr 2013, Randy Dunlap wrote: > On 04/17/13 16:12, David Rientjes wrote: > > The build fails when CONFIG_SMP is disabled: > > > > arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': > > arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in this > > function) > > > > Fix it by including the necessary header. > > Sorry, i386 build still fails with the same error message plus this one: > > ERROR: "apic" [arch/x86/kvm/kvm-intel.ko] undefined! > Ahh, that's because you don't have CONFIG_X86_LOCAL_APIC as you already mentioned. So it looks like this error can manifest in two different ways and we got different reports. This failure came from "KVM: VMX: Add the deliver posted interrupt algorithm", so adding Yang to the cc to specify the dependency this has on apic and how it can be protected without CONFIG_X86_LOCAL_APIC on i386. -- 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] slab: Remove unnecessary __builtin_constant_p()
On Wed, 17 Apr 2013, Steven Rostedt wrote:
> The slab.c code has a size check macro that checks the size of the
> following structs:
>
> struct arraycache_init
> struct kmem_list3
>
> The index_of() function that takes the sizeof() of the above two structs
> and does an unnecessary __builtin_constant_p() on that. As sizeof() will
> always end up being a constant making this always be true. The code is
> not incorrect, but it just adds added complexity, and confuses users and
> wastes the time of reviewers of the code, who spends time trying to
> figure out why the builtin_constant_p() was used.
>
> This patch is just a clean up that makes the index_of() code a little
> bit less complex.
>
> Signed-off-by: Steven Rostedt
Acked-by: David Rientjes
Adding Pekka to the cc.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 856e4a1..6047900 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -325,9 +325,7 @@ static void cache_reap(struct work_struct *unused);
> static __always_inline int index_of(const size_t size)
> {
> extern void __bad_size(void);
> -
> - if (__builtin_constant_p(size)) {
> - int i = 0;
> + int i = 0;
>
> #define CACHE(x) \
> if (size <=x) \
> @@ -336,9 +334,7 @@ static __always_inline int index_of(const size_t size)
> i++;
> #include
> #undef CACHE
> - __bad_size();
> - } else
> - __bad_size();
> + __bad_size();
> 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/
Re: [patch] x86, kvm: fix build failure with CONFIG_SMP disabled
On 04/17/13 16:12, David Rientjes wrote: > The build fails when CONFIG_SMP is disabled: > > arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': > arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in this > function) > > Fix it by including the necessary header. Sorry, i386 build still fails with the same error message plus this one: ERROR: "apic" [arch/x86/kvm/kvm-intel.ko] undefined! > Reported-by: Randy Dunlap > Signed-off-by: David Rientjes > --- > arch/x86/kvm/vmx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -34,6 +34,7 @@ > #include "kvm_cache_regs.h" > #include "x86.h" > > +#include > #include > #include > #include > -- -- ~Randy -- 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: PCI: Remove "extern" from function declarations
On Wed, Apr 17, 2013 at 5:24 PM, Stephen Rothwell wrote: > Hi Bjorn, > > I just noticed this commit (f39d5b72913e "PCI: Remove "extern" from > function declarations") in the pci next branch. Just wondering why you > would do such a thing. It is a lot of churn in quite a few header files > and (in my opinion) goes the wrong way anyway. > > It may not actually make any difference to the compiler for functions, but > for variables, it does. A variable declared in a header file without > "extern" will effectively define it in every compilation that includes > the header file, one with "extern" will only produce references. > > So, since, the global variables really should have the "extern", the > functions are now inconsistent with that. > > It also means that when someone copies a function declaration to make a > "static inline" stub, the "extern" is a big hint for them to remember to > make the stub "static" - I have seen several occasions when this was not > done and that causes compilation failures (but usually only in the > configuration that the author did not bother to test). Good points. The fact that some function declarations use "extern" and some don't is just an annoying inconsistency. I prefer fewer words to read, so I removed them, but that's just a personal preference, and I'd be OK it were always present, too. I suppose if anybody but me actually cared very much, we'd have checkpatch complain about one way or the other, but I don't think it does. Bjorn -- 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 5/7] Docs: Expectations for bug reporters and maintainers
On 04/17/2013 01:23:28 PM, Sarah Sharp wrote: On Tue, Apr 16, 2013 at 09:15:06PM -0500, Rob Landley wrote: > On 04/15/2013 12:33:34 PM, Sarah Sharp wrote: > >Outline how often it's polite to ping kernel maintainers about > >bugs, and > >suggest that kernel maintainers should respond to bugs in 1 to 5 > >business days. > > Is there anything in here about the four-level nature of modern > maintainership? > > Patches go from the developer, to the maintainer, to one of Linus's > lieutenants, to Linus himself. If you submit a patch to a maintainer > they owe you a response. The lieutenant (subsystem maintainer) owes > that maintainer a response, and Linus (the project's architect) owes > the lieutenant a response. Do we want to go into this much detail in a document meant for frustrated bug reporters? Or perhaps we should create a separate document about the kernel maintainer hierarchy and reference it here? My point was that you have to contact the right person to semi-reliably get a response, but you're right. That's more about getting patches in than getting problems reproduced and diagnosed. Also, please note that I'm writing this from the perspective of a driver maintainer. I'm not sure if we've met face to face. :) Pretty sure we haven't. (You helped me debug a weird usb3 issue once via email.) > Linus does not owe you, personally, a response. Neither do the > subsystem maintainers if you approach them directly with something > that should have gone through one of the hundreds of domain-specific > maintainers out of the Maintainers file. So the point of going to > the right people in sequence and getting their review and > signed-off-by lines is to ensure you don't sit there listening to > crickets chirping while your patch is ignored. (If you approach > Linus directly you may randomly _get_ a response, but there's no > guarantee, and usually you won't because he's really busy.) This file is about bug reporting, not submitting patches. I rewrote ... TLDR version: Yes, it would be nice if bug reporters could go up the hierarchy, but they don't have an easy way to know which subsystem maintainers to contact. Perhaps a new line in MAINTAINERS for the subsystem maintainer would be helpful? Eh, this has gone undocumented for a full decade and nobody but me's cared. It seemed related at the time (general interacting with the kernel developers), but I guess not. Rob-- 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: mmu_notifier: re-fix freed page still mapped in secondary MMU
Hi Robin,
On 04/16/2013 05:31 PM, Robin Holt wrote:
On Tue, Apr 16, 2013 at 02:39:49PM +0800, Xiao Guangrong wrote:
The commit 751efd8610d3 (mmu_notifier_unregister NULL Pointer deref
and multiple ->release()) breaks the fix:
3ad3d901bbcfb15a5e4690e55350db0899095a68
(mm: mmu_notifier: fix freed page still mapped in secondary MMU)
Can you describe how the page is still mapped? I thought I had all
cases covered. Whichever call hits first, I thought we had one callout
to the registered notifiers. Are you saying we need multiple callouts?
Also, shouldn't you be asking for a revert commit and then supply a
subsequent commit for the real fix? I thought that was the process for
doing a revert.
mmu_notifier is used for sync normal pte and spte, correct?
Thanks,
Robin Holt
This patch reverts the commit and simply fix the bug spotted
by that patch
This bug is spotted by commit 751efd8610d3:
==
There is a race condition between mmu_notifier_unregister() and
__mmu_notifier_release().
Assume two tasks, one calling mmu_notifier_unregister() as a result of a
filp_close() ->flush() callout (task A), and the other calling
mmu_notifier_release() from an mmput() (task B).
A B
t1 srcu_read_lock()
t2 if (!hlist_unhashed())
t3 srcu_read_unlock()
t4 srcu_read_lock()
t5 hlist_del_init_rcu()
t6 synchronize_srcu()
t7 srcu_read_unlock()
t8 hlist_del_rcu() <--- NULL pointer deref.
==
This can be fixed by using hlist_del_init_rcu instead of hlist_del_rcu.
The another issue spotted in the commit is
"multiple ->release() callouts", we needn't care it too much because
it is really rare (e.g, can not happen on kvm since mmu-notify is unregistered
after exit_mmap()) and the later call of multiple ->release should be
fast since all the pages have already been released by the first call.
Signed-off-by: Xiao Guangrong
---
mm/mmu_notifier.c | 81 +++--
1 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index be04122..606777a 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -40,48 +40,45 @@ void __mmu_notifier_release(struct mm_struct *mm)
int id;
/*
-* srcu_read_lock() here will block synchronize_srcu() in
-* mmu_notifier_unregister() until all registered
-* ->release() callouts this function makes have
-* returned.
+* SRCU here will block mmu_notifier_unregister until
+* ->release returns.
*/
id = srcu_read_lock();
+ hlist_for_each_entry_rcu(mn, >mmu_notifier_mm->list, hlist)
+ /*
+* if ->release runs before mmu_notifier_unregister it
+* must be handled as it's the only way for the driver
+* to flush all existing sptes and stop the driver
+* from establishing any more sptes before all the
+* pages in the mm are freed.
+*/
+ if (mn->ops->release)
+ mn->ops->release(mn, mm);
+ srcu_read_unlock(, id);
+
spin_lock(>mmu_notifier_mm->lock);
while (unlikely(!hlist_empty(>mmu_notifier_mm->list))) {
mn = hlist_entry(mm->mmu_notifier_mm->list.first,
struct mmu_notifier,
hlist);
-
/*
-* Unlink. This will prevent mmu_notifier_unregister()
-* from also making the ->release() callout.
+* We arrived before mmu_notifier_unregister so
+* mmu_notifier_unregister will do nothing other than
+* to wait ->release to finish and
+* mmu_notifier_unregister to return.
*/
hlist_del_init_rcu(>hlist);
- spin_unlock(>mmu_notifier_mm->lock);
-
- /*
-* Clear sptes. (see 'release' description in mmu_notifier.h)
-*/
- if (mn->ops->release)
- mn->ops->release(mn, mm);
-
- spin_lock(>mmu_notifier_mm->lock);
}
spin_unlock(>mmu_notifier_mm->lock);
/*
-* All callouts to ->release() which we have done are complete.
-* Allow synchronize_srcu() in mmu_notifier_unregister() to complete
-*/
- srcu_read_unlock(, id);
-
- /*
-* mmu_notifier_unregister() may have unlinked a notifier and may
-* still be calling out to it. Additionally, other notifiers
-* may have been active via vmtruncate() et. al. Block here
-* to ensure that all notifier callouts for this mm have been
-*
Re: [PATCH v3 07/15] KVM: MMU: introduce invalid rmap handlers
On Tue, Apr 16, 2013 at 02:32:45PM +0800, Xiao Guangrong wrote: > Invalid rmaps is the rmap of the invalid memslot which is being > deleted, especially, we can treat all rmaps are invalid when > kvm is being destroyed since all memslot will be deleted soon. > MMU should remove all sptes on these rmaps before the invalid > memslot fully deleted > > The reason why we separately handle invalid rmap is we want to > unmap invalid-rmap out of mmu-lock to achieve scale performance > on intensive memory and vcpu used guest Better try to make the code simpler, and introduce complexity only if necessary. The idea to zap the roots is very elegant and apparently effective. What are its problems? -- 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: Add a Kconfig shortcut for a kvm-bootable kernel
On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote: > On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote: > > On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote: > > > I obviously support having something like this in mainline. I wonder > > > though if we could just call this "default standalone KVM guest > > > config" instead of emphasizing testing angle. > > > > /me nods agreeingly... > > > > And it should be unter HYPERVISOR_GUEST where the rest of this stuff > > resides. Good point. > > Sanity check question: > > Why not add the select stuff, i.e. this: > > select NET > select NETDEVICES > select PCI > select BLOCK > select BLK_DEV > select NETWORK_FILESYSTEMS > select INET > select EXPERIMENTAL > select TTY > select SERIAL_8250 > select SERIAL_8250_CONSOLE > select IP_PNP > select IP_PNP_DHCP > select BINFMT_ELF > select PCI_MSI > select HAVE_ARCH_KGDB > select DEBUG_KERNEL > select KGDB > select KGDB_SERIAL_CONSOLE > select VIRTUALIZATION > select VIRTIO > select VIRTIO_RING > select VIRTIO_PCI > select VIRTIO_BLK > select VIRTIO_CONSOLE > select VIRTIO_NET > select 9P_FS > select NET_9P > select NET_9P_VIRTIO > > to the option below which we already have. It is in the same sense a KVM > guest support deal. > > Hmm. > > KVM people, any objections? None, but please don't mix it with 'KVM_GUEST' flag below. Actually, what about adding kvm variants of the two files at arch/x86/configs/ ? > config KVM_GUEST > bool "KVM Guest support (including kvmclock)" > depends on PARAVIRT > select PARAVIRT_CLOCK > default y > ---help--- > This option enables various optimizations for running under the KVM > hypervisor. It includes a paravirtualized clock, so that instead > of relying on a PIT (or probably other) emulation by the > underlying device model, the host provides the guest with > timing infrastructure such as time of day, and system time -- 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/RESEND] ARM: arch_timer: Silence debug preempt warnings
Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:
BUG: using smp_processor_id() in preemptible [] code: sh/111
caller is arch_timer_cpu_notify+0x14/0xc8
This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Mark Rutland
Acked-by: Marc Zyngier
Signed-off-by: Stephen Boyd
---
Resending to arm-soc maintainers instead of timekeeping maintainers. Who
maintains this driver?
drivers/clocksource/arm_arch_timer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..a65a710 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
clock_event_device *clk)
static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
- struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
-
+ /*
+* Grab cpu pointer in each case to avoid spurious
+* preemptible warnings
+*/
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
- arch_timer_setup(evt);
+ arch_timer_setup(this_cpu_ptr(arch_timer_evt));
break;
case CPU_DYING:
- arch_timer_stop(evt);
+ arch_timer_stop(this_cpu_ptr(arch_timer_evt));
break;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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.8-stable] regmap: irq: call pm_runtime_put in pm_runtime_get_sync
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "Li Fei "
commit 283189d3be56aa6db6f192bb255df68493cd79ac upstream.
Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put(_sync) in such case.
Signed-off-by Liu Chuansheng
Signed-off-by: Li Fei
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
drivers/base/regmap/regmap-irq.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/regmap/regmap-irq.c
b/drivers/base/regmap/regmap-irq.c
index 5972ad9..d623eea 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -167,6 +167,7 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
if (ret < 0) {
dev_err(map->dev, "IRQ thread failed to resume:
%d\n",
ret);
+ pm_runtime_put(map->dev);
return IRQ_NONE;
}
}
--
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: PCI: Remove "extern" from function declarations
Hi Bjorn, I just noticed this commit (f39d5b72913e "PCI: Remove "extern" from function declarations") in the pci next branch. Just wondering why you would do such a thing. It is a lot of churn in quite a few header files and (in my opinion) goes the wrong way anyway. It may not actually make any difference to the compiler for functions, but for variables, it does. A variable declared in a header file without "extern" will effectively define it in every compilation that includes the header file, one with "extern" will only produce references. So, since, the global variables really should have the "extern", the functions are now inconsistent with that. It also means that when someone copies a function declaration to make a "static inline" stub, the "extern" is a big hint for them to remember to make the stub "static" - I have seen several occasions when this was not done and that causes compilation failures (but usually only in the configuration that the author did not bother to test). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgppSvNDIimC5.pgp Description: PGP signature
[PATCH v2 4/4] Simple correctness and speed test for CRCT10DIF hash
These are simple tests to do sanity check of CRC T10 DIF hash. The
correctness of the transform can be checked with the command
modprobe tcrypt mode=47
The speed of the transform can be evaluated with the command
modprobe tcrypt mode=320
Set the cpu frequency to constant and turn turbo off when running the
speed test so the frequency governor will not tweak the frequency and
affects the measurements.
Signed-off-by: Tim Chen
---
crypto/tcrypt.c | 8
crypto/testmgr.c | 10 ++
crypto/testmgr.h | 33 +
3 files changed, 51 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 24ea7df..5e95722 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1174,6 +1174,10 @@ static int do_test(int m)
ret += tcrypt_test("ghash");
break;
+ case 47:
+ ret += tcrypt_test("crct10dif");
+ break;
+
case 100:
ret += tcrypt_test("hmac(md5)");
break;
@@ -1498,6 +1502,10 @@ static int do_test(int m)
test_hash_speed("crc32c", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
+ case 320:
+ test_hash_speed("crct10dif", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
case 399:
break;
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 3807084..b165316 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1944,6 +1944,16 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "crct10dif",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = crct10dif_tv_template,
+ .count = CRCT10DIF_TEST_VECTORS
+ }
+ }
+ }, {
.alg = "cryptd(__driver-cbc-aes-aesni)",
.test = alg_test_null,
.fips_allowed = 1,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index d503660..56916d0 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -450,6 +450,39 @@ static struct hash_testvec rmd320_tv_template[] = {
}
};
+#define CRCT10DIF_TEST_VECTORS 3
+static struct hash_testvec crct10dif_tv_template[] = {
+ {
+ .plaintext = "abc",
+ .psize = 3,
+#ifdef __LITTLE_ENDIAN
+ .digest = "\x3b\x44",
+#else
+ .digest = "\x44\x3b",
+#endif
+ }, {
+ .plaintext = "1234567890123456789012345678901234567890"
+"123456789012345678901234567890123456789",
+ .psize = 79,
+#ifdef __LITTLE_ENDIAN
+ .digest = "\x70\x4b",
+#else
+ .digest = "\x4b\x70",
+#endif
+ }, {
+ .plaintext =
+ "abcd",
+ .psize = 56,
+#ifdef __LITTLE_ENDIAN
+ .digest = "\xe3\x9c",
+#else
+ .digest = "\x9c\xe3",
+#endif
+ .np = 2,
+ .tap= { 28, 28 }
+ }
+};
+
/*
* SHA1 test vectors from from FIPS PUB 180-1
* Long vector from CAVS 5.0
--
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 v2 2/4] Accelerated CRC T10 DIF computation with PCLMULQDQ instruction
This is the x86_64 CRC T10 DIF transform accelerated with the PCLMULQDQ instructions. Details discussing the implementation can be found in the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction" http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf Signed-off-by: Tim Chen --- arch/x86/crypto/crct10dif-pcl-asm_64.S | 643 + 1 file changed, 643 insertions(+) create mode 100644 arch/x86/crypto/crct10dif-pcl-asm_64.S diff --git a/arch/x86/crypto/crct10dif-pcl-asm_64.S b/arch/x86/crypto/crct10dif-pcl-asm_64.S new file mode 100644 index 000..35e9756 --- /dev/null +++ b/arch/x86/crypto/crct10dif-pcl-asm_64.S @@ -0,0 +1,643 @@ + +# Implement fast CRC-T10DIF computation with SSE and PCLMULQDQ instructions +# +# Copyright (c) 2013, Intel Corporation +# +# Authors: +# Erdinc Ozturk +# Vinodh Gopal +# James Guilford +# Tim Chen +# +# This software is available to you under a choice of one of two +# licenses. You may choose to be licensed under the terms of the GNU +# General Public License (GPL) Version 2, available from the file +# COPYING in the main directory of this source tree, or the +# OpenIB.org BSD license below: +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions are +# met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in the +# documentation and/or other materials provided with the +# distribution. +# +# * Neither the name of the Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived from +# this software without specific prior written permission. +# +# +# THIS SOFTWARE IS PROVIDED BY INTEL CORPORATION ""AS IS"" AND ANY +# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INTEL CORPORATION OR +# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, +# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF +# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS +# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +# Function API: +# UINT16 crc_t10dif_pcl( +# UINT16 init_crc, //initial CRC value, 16 bits +# const unsigned char *buf, //buffer pointer to calculate CRC on +# UINT64 len //buffer length in bytes (64-bit data) +# ); +# +# Reference paper titled "Fast CRC Computation for Generic +# Polynomials Using PCLMULQDQ Instruction" +# URL: http://www.intel.com/content/dam/www/public/us/en/documents +# /white-papers/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf +# +# + +#include + +.text + +#definearg1 %rdi +#definearg2 %rsi +#definearg3 %rdx + +#definearg1_low32 %edi + +ENTRY(crc_t10dif_pcl) +.align 16 + + # adjust the 16-bit initial_crc value, scale it to 32 bits + shl $16, arg1_low32 + + # Allocate Stack Space + mov %rsp, %rcx + sub $16*2, %rsp + # align stack to 16 byte boundary + and $~(0x10 - 1), %rsp + + # check if smaller than 256 + cmp $256, arg3 + + # for sizes less than 128, we can't fold 64B at a time... + jl _less_than_128 + + + # load the initial crc value + movdarg1_low32, %xmm10 # initial crc + + # crc value does not need to be byte-reflected, but it needs + # to be moved to the high part of the register. + # because data will be byte-reflected and will align with + # initial crc at correct place. + pslldq $12, %xmm10 + + movdqa SHUF_MASK(%rip), %xmm11 + # receive the initial 64B data, xor the initial crc value + movdqu 16*0(arg2), %xmm0 + movdqu 16*1(arg2), %xmm1 + movdqu 16*2(arg2), %xmm2 + movdqu 16*3(arg2), %xmm3 + movdqu 16*4(arg2), %xmm4 + movdqu 16*5(arg2), %xmm5 + movdqu 16*6(arg2), %xmm6 + movdqu 16*7(arg2), %xmm7 + + pshufb %xmm11, %xmm0 + # XOR the initial_crc value + pxor%xmm10, %xmm0 + pshufb %xmm11, %xmm1 + pshufb %xmm11, %xmm2
[PATCH v2 3/4] Glue code to cast accelerated CRCT10DIF assembly as a crypto transform
Glue code that plugs the PCLMULQDQ accelerated CRC T10 DIF hash into the
crypto framework. The config CRYPTO_CRCT10DIF_PCLMUL should be turned
on to enable the feature. The crc_t10dif crypto library function will
use this faster algorithm when crct10dif_pclmul module is loaded.
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile| 2 +
arch/x86/crypto/crct10dif-pclmul_glue.c | 153
crypto/Kconfig | 21 +
3 files changed, 176 insertions(+)
create mode 100644 arch/x86/crypto/crct10dif-pclmul_glue.c
diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 03cd731..d544a66 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CRYPTO_SHA1_SSSE3) += sha1-ssse3.o
obj-$(CONFIG_CRYPTO_CRC32_PCLMUL) += crc32-pclmul.o
obj-$(CONFIG_CRYPTO_SHA256_SSSE3) += sha256-ssse3.o
obj-$(CONFIG_CRYPTO_SHA512_SSSE3) += sha512-ssse3.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF_PCLMUL) += crct10dif-pclmul.o
# These modules require assembler to support AVX.
ifeq ($(avx_supported),yes)
@@ -70,3 +71,4 @@ crc32c-intel-$(CONFIG_64BIT) += crc32c-pcl-intel-asm_64.o
crc32-pclmul-y := crc32-pclmul_asm.o crc32-pclmul_glue.o
sha256-ssse3-y := sha256-ssse3-asm.o sha256-avx-asm.o sha256-avx2-asm.o
sha256_ssse3_glue.o
sha512-ssse3-y := sha512-ssse3-asm.o sha512-avx-asm.o sha512-avx2-asm.o
sha512_ssse3_glue.o
+crct10dif-pclmul-y := crct10dif-pcl-asm_64.o crct10dif-pclmul_glue.o
diff --git a/arch/x86/crypto/crct10dif-pclmul_glue.c
b/arch/x86/crypto/crct10dif-pclmul_glue.c
new file mode 100644
index 000..e87f8d8
--- /dev/null
+++ b/arch/x86/crypto/crct10dif-pclmul_glue.c
@@ -0,0 +1,153 @@
+/*
+ * Cryptographic API.
+ *
+ * T10 Data Integrity Field CRC16 Crypto Xform using PCLMULQDQ Instructions
+ *
+ * Copyright (C) 2013 Intel Corporation
+ * Author: Tim Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+asmlinkage __u16 crc_t10dif_pcl(__u16 crc, const unsigned char *buf,
+ size_t len);
+
+struct chksum_desc_ctx {
+ __u16 crc;
+};
+
+/*
+ * Steps through buffer one byte at at time, calculates reflected
+ * crc using table.
+ */
+
+static int chksum_init(struct shash_desc *desc)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ ctx->crc = 0;
+
+ return 0;
+}
+
+static int chksum_update(struct shash_desc *desc, const u8 *data,
+unsigned int length)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ if (irq_fpu_usable()) {
+ kernel_fpu_begin();
+ ctx->crc = crc_t10dif_pcl(ctx->crc, data, length);
+ kernel_fpu_end();
+ } else
+ ctx->crc = crc_t10dif_generic(ctx->crc, data, length);
+ return 0;
+}
+
+static int chksum_final(struct shash_desc *desc, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ *(__u16 *)out = ctx->crc;
+ return 0;
+}
+
+static int __chksum_finup(__u16 *crcp, const u8 *data, unsigned int len,
+ u8 *out)
+{
+ if (irq_fpu_usable()) {
+ kernel_fpu_begin();
+ *(__u16 *)out = crc_t10dif_pcl(*crcp, data, len);
+ kernel_fpu_end();
+ } else
+ *(__u16 *)out = crc_t10dif_generic(*crcp, data, len);
+ return 0;
+}
+
+static int chksum_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int len, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(>crc, data, len, out);
+}
+
+static int chksum_digest(struct shash_desc *desc, const u8 *data,
+unsigned int length, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(>crc, data, length, out);
+}
+
+static struct shash_alg alg = {
+ .digestsize = CRC_T10DIF_DIGEST_SIZE,
+ .init = chksum_init,
+ .update = chksum_update,
+ .final = chksum_final,
+ .finup = chksum_finup,
+
[PATCH v2 0/4] Patchset to use PCLMULQDQ to accelerate CRC-T10DIF checksum computation
Currently the CRC-T10DIF checksum is computed using a generic table lookup algorithm. By switching the checksum to PCLMULQDQ based computation, we can speedup the computation by 8x for checksumming 512 bytes and even more for larger buffer size. This will improve performance of SCSI drivers turning on the CRC-T10IDF checksum. In our SSD based experiments, we have seen increase disk throughput by 3.5x with T10DIF for 512 byte block size. This patch set provides the x86_64 routine using PCLMULQDQ instruction and switches the crc_t10dif library function to use the faster PCLMULQDQ based routine when available. Tim v1->v2 1. Get rid of unnecessary xmm registers save and restore and fix ENDPROC position in PCLMULQDQ version of crc t10dif computation. 2. Fix URL to paper reference of CRC computation with PCLMULQDQ. 3. Add one additional tcrypt test case to exercise more code paths through crc t10dif computation. 4. Fix config dependencies of CRYPTO_CRCT10DIF. Thanks to Matthew and Jussi who reviewed the patches and Keith for testing version 1 of the patch set. Tim Chen (4): Wrap crc_t10dif function all to use crypto transform framework Accelerated CRC T10 DIF computation with PCLMULQDQ instruction Glue code to cast accelerated CRCT10DIF assembly as a crypto transform Simple correctness and speed test for CRCT10DIF hash arch/x86/crypto/Makefile| 2 + arch/x86/crypto/crct10dif-pcl-asm_64.S | 643 arch/x86/crypto/crct10dif-pclmul_glue.c | 153 crypto/Kconfig | 21 ++ crypto/tcrypt.c | 8 + crypto/testmgr.c| 10 + crypto/testmgr.h| 33 ++ include/linux/crc-t10dif.h | 10 + lib/crc-t10dif.c| 96 + 9 files changed, 976 insertions(+) create mode 100644 arch/x86/crypto/crct10dif-pcl-asm_64.S create mode 100644 arch/x86/crypto/crct10dif-pclmul_glue.c -- 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 v2 1/4] Wrap crc_t10dif function all to use crypto transform framework
When CRC T10 DIF is calculated using the crypto transform framework, we
wrap the crc_t10dif function call to utilize it. This allows us to
take advantage of any accelerated CRC T10 DIF transform that is
plugged into the crypto framework.
Signed-off-by: Tim Chen
---
include/linux/crc-t10dif.h | 10 +
lib/crc-t10dif.c | 96 ++
2 files changed, 106 insertions(+)
diff --git a/include/linux/crc-t10dif.h b/include/linux/crc-t10dif.h
index a9c96d8..f0eb4d5 100644
--- a/include/linux/crc-t10dif.h
+++ b/include/linux/crc-t10dif.h
@@ -3,6 +3,16 @@
#include
+#ifdef CONFIG_CRYPTO_CRCT10DIF
+
+#define CRC_T10DIF_DIGEST_SIZE 2
+#define CRC_T10DIF_BLOCK_SIZE 1
+
+__u16 crc_t10dif_generic(__u16 crc, const unsigned char *buffer, size_t len);
+void crc_t10dif_update_lib(void);
+
+#endif /* CONFIG_CRYPTO_CRCT10DIF */
+
__u16 crc_t10dif(unsigned char const *, size_t);
#endif
diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c
index fbbd66e..41f469a 100644
--- a/lib/crc-t10dif.c
+++ b/lib/crc-t10dif.c
@@ -11,6 +11,9 @@
#include
#include
#include
+#include
+#include
+#include
/* Table generated using the following polynomium:
* x^16 + x^15 + x^11 + x^9 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
@@ -51,6 +54,98 @@ static const __u16 t10_dif_crc_table[256] = {
0xF0D8, 0x7B6F, 0x6C01, 0xE7B6, 0x42DD, 0xC96A, 0xDE04, 0x55B3
};
+#ifdef CONFIG_CRYPTO_CRCT10DIF
+
+static struct crypto_shash *crct10dif_tfm;
+
+/* flag to indicate update to new algorithm in progress*/
+static bool crc_t10dif_newalg;
+
+__u16 crc_t10dif_generic(__u16 crc, const unsigned char *buffer, size_t len)
+{
+ unsigned int i;
+
+ for (i = 0 ; i < len ; i++)
+ crc = (crc << 8) ^ t10_dif_crc_table[((crc >> 8) ^ buffer[i]) &
0xff];
+
+ return crc;
+}
+EXPORT_SYMBOL(crc_t10dif_generic);
+
+/*
+ * If we have defined crypto transform for CRC-T10DIF, use that instead.
+ * This allows us to plug in fast version of CRC-T10DIF when available.
+ */
+
+void crc_t10dif_update_lib()
+{
+ struct crypto_shash *old_tfm, *new_tfm;
+
+ old_tfm = crct10dif_tfm;
+ crc_t10dif_newalg = true;
+ /* make sure new alg flag is turned on before starting to switch tfm */
+ mb();
+
+ new_tfm = crypto_alloc_shash("crct10dif", 0, 0);
+ if (IS_ERR(new_tfm))
+ goto done;
+
+ if (old_tfm)
+ if (crypto_tfm_alg_priority(_tfm->base) >=
+ crypto_tfm_alg_priority(_tfm->base)) {
+ crypto_free_shash(new_tfm);
+ goto done;
+ }
+ crct10dif_tfm = new_tfm;
+ /* make sure update to tfm pointer is completed */
+ mb();
+ crypto_free_shash(old_tfm);
+
+done:
+ crc_t10dif_newalg = false;
+}
+EXPORT_SYMBOL(crc_t10dif_update_lib);
+
+__u16 crc_t10dif(const unsigned char *buffer, size_t len)
+{
+ struct {
+ struct shash_desc shash;
+ char ctx[2];
+ } desc;
+ int err;
+
+ /* plugging in new alg or not using a tfm? */
+ if (unlikely(crc_t10dif_newalg) || (!crct10dif_tfm))
+ return crc_t10dif_generic(0, buffer, len);
+
+ desc.shash.tfm = crct10dif_tfm;
+ desc.shash.flags = 0;
+ *(__u16 *)desc.ctx = 0;
+
+ err = crypto_shash_update(, buffer, len);
+ BUG_ON(err);
+
+ return *(__u16 *)desc.ctx;
+}
+EXPORT_SYMBOL(crc_t10dif);
+
+static int __init crc_t10dif_mod_init(void)
+{
+ crct10dif_tfm = NULL;
+ crc_t10dif_newalg = false;
+ return 0;
+}
+
+static void __exit crc_t10dif_mod_fini(void)
+{
+ if (crct10dif_tfm)
+ crypto_free_shash(crct10dif_tfm);
+}
+
+module_init(crc_t10dif_mod_init);
+module_exit(crc_t10dif_mod_fini);
+
+#else
__u16 crc_t10dif(const unsigned char *buffer, size_t len)
{
__u16 crc = 0;
@@ -62,6 +157,7 @@ __u16 crc_t10dif(const unsigned char *buffer, size_t len)
return crc;
}
EXPORT_SYMBOL(crc_t10dif);
+#endif
MODULE_DESCRIPTION("T10 DIF CRC calculation");
MODULE_LICENSE("GPL");
--
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] x86, kvm: fix build failure with CONFIG_SMP disabled
The build fails when CONFIG_SMP is disabled: arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in this function) Fix it by including the necessary header. Reported-by: Randy Dunlap Signed-off-by: David Rientjes --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -34,6 +34,7 @@ #include "kvm_cache_regs.h" #include "x86.h" +#include #include #include #include -- 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/
mmotm 2013-04-17-16-02 uploaded
The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.9-rc7: (patches marked "*" will be included in linux-next) origin.patch thinkpad-acpi-kill-hotkey_thread_mutex.patch drivers-video-mmp-corec-fix-use-after-free-bug.patch checkpatch-fix-stringification-macro-defect.patch hugetlbfs-stop-setting-vm_dontdump-in-initializing-vmavm_hugetlb.patch fix-hugetlb-memory-check-in-vma_dump_size.patch hugetlbfs-add-swap-entry-check-in-follow_hugetlb_page.patch avr32-fix-build-error-in-atstk1006_defconfig.patch hfsplus-fix-potential-overflow-in-hfsplus_file_truncate.patch mm-vmscan-fix-error-return-in-kswapd_run.patch signal-stop-info-leak-via-the-tkill-and-the-tgkill-syscalls.patch linux-next.patch arch-alpha-kernel-systblss-remove-debug-check.patch i-need-old-gcc.patch * revert-ipc-dont-allocate-a-copy-larger-than-max.patch * drivers-char-randomc-fix-priming-of-last_data.patch * kthread-introduce-to_live_kthread.patch * kthread-kill-task_get_live_kthread.patch * x86-make-mem=-option-to-work-for-efi-platform.patch * auditsc-use-kzalloc-instead-of-kmallocmemset.patch * auditsc-use-kzalloc-instead-of-kmallocmemset-fix.patch * audit-dont-check-if-kauditd-is-valid-every-time.patch * audit-remove-duplicate-export-of-audit_enabled.patch * audit-remove-unnecessary-if-config_audit.patch * kernel-auditfilter-resource-management-tree-and-watch-will-memory-leak-when-failure-occurs.patch * mm-remove-free_area_cache-use-in-powerpc-architecture.patch * mm-use-vm_unmapped_area-on-powerpc-architecture.patch * drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch * matroxfb-convert-struct-i2c_msg-initialization-to-c99-format.patch * drivers-video-console-fbcon_cwc-fix-compiler-warning-in-cw_update_attr.patch * drivers-video-add-hyper-v-synthetic-video-frame-buffer-driver.patch * drivers-video-add-hyper-v-synthetic-video-frame-buffer-driver-fix.patch * drivers-video-exynos-exynos_mipi_dsic-convert-to-devm_ioremap_resource.patch * video-ep93xx-fbc-fix-section-mismatch-and-use-module_platform_driver.patch * drivers-video-mmp-remove-legacy-hw-definitions.patch * drivers-video-implement-a-simple-framebuffer-driver.patch * drivers-video-implement-a-simple-framebuffer-driver-fix.patch * cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch * timer_list-split-timer_list_show_tickdevices.patch * timer_list-convert-timer-list-to-be-a-proper-seq_file.patch * timer_list-convert-timer-list-to-be-a-proper-seq_file-v5.patch * posix_cpu_timer-consolidate-expiry-time-type.patch * posix_cpu_timers-consolidate-timer-list-cleanups.patch * posix_cpu_timers-consolidate-expired-timers-check.patch *
[git pull] idle patches for 3.9-rc7
Hi Linus, Please pull this pair of small patches into 3.9-rc7. This CPU-id should have been included in the ones that we updated earlier in 3.9. This pair of patches will allow this flavor of Haswell to behave like the other flavors. thanks! Len Brown, Intel Open Source Technology Center The following changes since commit a2362d24764a4e9a3187fc46b14e1d2cd0657700: mm/fremap.c: fix possible oops on error path (2013-03-14 17:00:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git release for you to fetch changes up to 149c2319c6316d979de90ce2c8665e9c02d5927b: tools/power turbostat: additional Haswell CPU-id (2013-03-15 11:05:26 -0400) Len Brown (2): intel_idle: additional Haswell CPU-id tools/power turbostat: additional Haswell CPU-id drivers/idle/intel_idle.c | 1 + tools/power/x86/turbostat/turbostat.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) -- 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/
[tip:x86/kdump] kexec: use Crash kernel for Crash kernel low
Commit-ID: 157752d84f5df47e01577970f9c5f61a0b9f4546
Gitweb: http://git.kernel.org/tip/157752d84f5df47e01577970f9c5f61a0b9f4546
Author: Yinghai Lu
AuthorDate: Mon, 15 Apr 2013 22:23:46 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 17 Apr 2013 12:35:34 -0700
kexec: use Crash kernel for Crash kernel low
We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
instead.
So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.
Suggested-by: Vivek Goyal
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1366089828-19692-3-git-send-email-ying...@kernel.org
Acked-by: Vivek Goyal
Signed-off-by: H. Peter Anvin
---
kernel/kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 401fdb0..ffd4e11 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -55,7 +55,7 @@ struct resource crashk_res = {
.flags = IORESOURCE_BUSY | IORESOURCE_MEM
};
struct resource crashk_low_res = {
- .name = "Crash kernel low",
+ .name = "Crash kernel",
.start = 0,
.end = 0,
.flags = IORESOURCE_BUSY | IORESOURCE_MEM
--
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/
[tip:x86/kdump] x86, kdump: Change crashkernel_high/low= to crashkernel=,high/low
Commit-ID: adbc742bf78695bb98c79d18c558b61571748b99
Gitweb: http://git.kernel.org/tip/adbc742bf78695bb98c79d18c558b61571748b99
Author: Yinghai Lu
AuthorDate: Mon, 15 Apr 2013 22:23:48 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 17 Apr 2013 12:35:33 -0700
x86, kdump: Change crashkernel_high/low= to crashkernel=,high/low
Per hpa, use crashkernel=X,high crashkernel=Y,low instead of
crashkernel_hign=X crashkernel_low=Y. As that could be extensible.
-v2: according to Vivek, change delimiter to ;
-v3: let hign and low only handle simple form and it conforms to
description in kernel-parameters.txt
still keep crashkernel=X override any crashkernel=X,high
crashkernel=Y,low
-v4: update get_last_crashkernel returning and add more strict
checking in parse_crashkernel_simple() found by HATAYAMA.
-v5: Change delimiter back to , according to HPA.
also separate parse_suffix from parse_simper according to vivek.
so we can avoid @pos in that path.
-v6: Tight the checking about crashkernel=X,highblahblah,high
found by HTYAYAMA.
Cc: HATAYAMA Daisuke
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1366089828-19692-5-git-send-email-ying...@kernel.org
Acked-by: Vivek Goyal
Signed-off-by: H. Peter Anvin
---
Documentation/kernel-parameters.txt | 10 ++--
arch/x86/kernel/setup.c | 6 +-
kernel/kexec.c | 109 +++-
3 files changed, 104 insertions(+), 21 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 709eb3ed..a1ac1f1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -603,16 +603,16 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
a memory unit (amount[KMG]). See also
Documentation/kdump/kdump.txt for an example.
- crashkernel_high=size[KMG]
+ crashkernel=size[KMG],high
[KNL, x86_64] range could be above 4G. Allow kernel
to allocate physical memory region from top, so could
be above 4G if system have more than 4G ram installed.
Otherwise memory region will be allocated below 4G, if
available.
It will be ignored if crashkernel=X is specified.
- crashkernel_low=size[KMG]
- [KNL, x86_64] range under 4G. When crashkernel_high= is
- passed, kernel could allocate physical memory region
+ crashkernel=size[KMG],low
+ [KNL, x86_64] range under 4G. When crashkernel=X,high
+ is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
requires at least 64M+32K low memory. Kernel would
@@ -620,7 +620,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
This one let user to specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
- It will be ignored when crashkernel_high=X is not used
+ It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
cs89x0_dma= [HW,NET]
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a85a144..fae9134 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -528,7 +528,7 @@ static void __init reserve_crashkernel_low(void)
int ret;
total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
- /* crashkernel_low=YM */
+ /* crashkernel=Y,low */
ret = parse_crashkernel_low(boot_command_line, total_low_mem,
_size, );
if (ret != 0) {
@@ -542,7 +542,7 @@ static void __init reserve_crashkernel_low(void)
low_size = swiotlb_size_or_default() + (8UL<<20);
auto_set = true;
} else {
- /* passed with crashkernel_low=0 ? */
+ /* passed with crashkernel=0,low ? */
if (!low_size)
return;
}
@@ -582,7 +582,7 @@ static void __init reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, total_mem,
_size, _base);
if (ret != 0 || crash_size <= 0) {
- /* crashkernel_high=XM */
+ /* crashkernel=X,high */
ret = parse_crashkernel_high(boot_command_line, total_mem,
_size, _base);
if (ret != 0 || crash_size <= 0)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 1b2f73f..401fdb0 100644
---
Re: linux-next: Tree for Apr 17 (kvm)
On Wed, 17 Apr 2013, Randy Dunlap wrote: > On 04/17/13 00:04, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20130416: > > > > > on i386, SMP is disabled, X86_UP_APIC is not enabled, but > CONFIG_KVM_APIC_ARCHITECTURE=y: > > arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt': > arch/x86/kvm/vmx.c:3950:3: error: 'apic' undeclared (first use in this > function) > Confirmed this happens on x86_64 as well, it seems that CONFIG_SMP=n is the key. -- 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] net-sysfs: Add entry for nl80211 interface type
Hi Bing, > Add a "wireless/nl80211_iftype" entry in the net device sysfs > file structure to indicate the mode of the wireless device so > it can be discovered easily from userspace. I do question a little bit the usefulness for this one. It would only work on netdev and on wdev devices. Using nl80211 to discover this information seems a lot better approach. Regards Marcel -- 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/
[tip:x86/kdump] x86, kdump: Retore crashkernel= to allocate under 896M
Commit-ID: 55a20ee7804ab64ac90bcdd4e2868a42829e2784
Gitweb: http://git.kernel.org/tip/55a20ee7804ab64ac90bcdd4e2868a42829e2784
Author: Yinghai Lu
AuthorDate: Mon, 15 Apr 2013 22:23:47 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 17 Apr 2013 12:35:33 -0700
x86, kdump: Retore crashkernel= to allocate under 896M
Vivek found old kexec-tools does not work new kernel anymore.
So change back crashkernel= back to old behavoir, and add crashkernel_high=
to let user decide if buffer could be above 4G, and also new kexec-tools will
be needed.
-v2: let crashkernel=X override crashkernel_high=
update description about _high will be ignored by crashkernel=X
-v3: update description about kernel-parameters.txt according to Vivek.
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1366089828-19692-4-git-send-email-ying...@kernel.org
Acked-by: Vivek Goyal
Signed-off-by: H. Peter Anvin
---
Documentation/kernel-parameters.txt | 13 +++--
arch/x86/kernel/setup.c | 24 +++-
include/linux/kexec.h | 2 ++
kernel/kexec.c | 9 +
4 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index cff672d..709eb3ed 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -603,9 +603,16 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
a memory unit (amount[KMG]). See also
Documentation/kdump/kdump.txt for an example.
+ crashkernel_high=size[KMG]
+ [KNL, x86_64] range could be above 4G. Allow kernel
+ to allocate physical memory region from top, so could
+ be above 4G if system have more than 4G ram installed.
+ Otherwise memory region will be allocated below 4G, if
+ available.
+ It will be ignored if crashkernel=X is specified.
crashkernel_low=size[KMG]
- [KNL, x86_64] range under 4G. When crashkernel= is
- passed, kernel allocate physical memory region
+ [KNL, x86_64] range under 4G. When crashkernel_high= is
+ passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
requires at least 64M+32K low memory. Kernel would
@@ -613,6 +620,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
This one let user to specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
+ It will be ignored when crashkernel_high=X is not used
+ or memory reserved is below 4G.
cs89x0_dma= [HW,NET]
Format:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1234920..a85a144 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -507,11 +507,14 @@ static void __init
memblock_x86_reserve_range_setup_data(void)
/*
* Keep the crash kernel below this limit. On 32 bits earlier kernels
* would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64bit, old kexec-tools need to under 896MiB.
*/
#ifdef CONFIG_X86_32
-# define CRASH_KERNEL_ADDR_MAX (512 << 20)
+# define CRASH_KERNEL_ADDR_LOW_MAX (512 << 20)
+# define CRASH_KERNEL_ADDR_HIGH_MAX(512 << 20)
#else
-# define CRASH_KERNEL_ADDR_MAX MAXMEM
+# define CRASH_KERNEL_ADDR_LOW_MAX (896UL<<20)
+# define CRASH_KERNEL_ADDR_HIGH_MAXMAXMEM
#endif
static void __init reserve_crashkernel_low(void)
@@ -525,6 +528,7 @@ static void __init reserve_crashkernel_low(void)
int ret;
total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
+ /* crashkernel_low=YM */
ret = parse_crashkernel_low(boot_command_line, total_low_mem,
_size, );
if (ret != 0) {
@@ -569,14 +573,22 @@ static void __init reserve_crashkernel(void)
const unsigned long long alignment = 16<<20;/* 16M */
unsigned long long total_mem;
unsigned long long crash_size, crash_base;
+ bool high = false;
int ret;
total_mem = memblock_phys_mem_size();
+ /* crashkernel=XM */
ret = parse_crashkernel(boot_command_line, total_mem,
_size, _base);
- if (ret != 0 || crash_size <= 0)
- return;
+ if (ret != 0 || crash_size <= 0) {
+ /* crashkernel_high=XM */
+ ret = parse_crashkernel_high(boot_command_line, total_mem,
+ _size, _base);
+
[tip:x86/kdump] x86, kdump: Set crashkernel_low automatically
Commit-ID: c729de8fcea37a1c444e81857eace12494c804a9
Gitweb: http://git.kernel.org/tip/c729de8fcea37a1c444e81857eace12494c804a9
Author: Yinghai Lu
AuthorDate: Mon, 15 Apr 2013 22:23:45 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 17 Apr 2013 12:35:32 -0700
x86, kdump: Set crashkernel_low automatically
Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.
We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y. This causes regression
if iommu is not enabled. Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.
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.
-v4: add comments what 8M is for according to hpa.
also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.
-v6: Change description about swiotlb referring according to HATAYAMA.
Reported-by: WANG Chao
Tested-by: WANG Chao
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1366089828-19692-2-git-send-email-ying...@kernel.org
Acked-by: Vivek Goyal
Signed-off-by: H. Peter Anvin
---
Documentation/kernel-parameters.txt | 14 +++---
arch/x86/kernel/setup.c | 21 ++---
include/linux/swiotlb.h | 1 +
lib/swiotlb.c | 19 +++
4 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4609e81..cff672d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
is selected automatically. Check
Documentation/kdump/kdump.txt for further details.
- crashkernel_low=size[KMG]
- [KNL, x86] parts under 4G.
-
crashkernel=range1:size1[,range2:size2,...][@offset]
[KNL] Same as above, but depends on the memory
in the running system. The syntax of range is
@@ -606,6 +603,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
a memory unit (amount[KMG]). See also
Documentation/kdump/kdump.txt for an example.
+ crashkernel_low=size[KMG]
+ [KNL, x86_64] range under 4G. When crashkernel= is
+ passed, kernel allocate physical memory region
+ above 4G, that cause second kernel crash on system
+ that require some amount of low memory, e.g. swiotlb
+ requires at least 64M+32K low memory. Kernel would
+ try to allocate 72M below 4G automatically.
+ This one let user to specify own low range under 4G
+ for second kernel instead.
+ 0: to disable low allocation.
+
cs89x0_dma= [HW,NET]
Format:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..1234920 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -521,19 +521,34 @@ static void __init reserve_crashkernel_low(void)
unsigned long long low_base = 0, low_size = 0;
unsigned long total_low_mem;
unsigned long long base;
+ bool auto_set = false;
int ret;
total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
ret = parse_crashkernel_low(boot_command_line, total_low_mem,
_size, );
- if (ret != 0 || low_size <= 0)
- return;
+ if (ret != 0) {
+ /*
+* two parts from lib/swiotlb.c:
+* swiotlb size: user specified with swiotlb= or default.
+* swiotlb overflow buffer: now is hardcoded to 32k.
+* We round it to 8M for other buffers that
+* may need to stay low too.
+*/
+ low_size = swiotlb_size_or_default() + (8UL<<20);
+ auto_set = true;
+ } else {
+ /* passed with crashkernel_low=0 ? */
+ if (!low_size)
+ return;
+ }
low_base = memblock_find_in_range(low_size, (1ULL<<32),
low_size, alignment);
if (!low_base) {
- pr_info("crashkernel low reservation
[PATCH 1/2] intel_idle: additional Haswell CPU-id
From: Len Brown
There is an additional HSW CPU-id, 0x46,
which has C-states exactly like CPU-id 0x45.
Signed-off-by: Len Brown
---
drivers/idle/intel_idle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 5d66750..1a38dd7 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -465,6 +465,7 @@ static const struct x86_cpu_id intel_idle_ids[] = {
ICPU(0x3c, idle_cpu_hsw),
ICPU(0x3f, idle_cpu_hsw),
ICPU(0x45, idle_cpu_hsw),
+ ICPU(0x46, idle_cpu_hsw),
{}
};
MODULE_DEVICE_TABLE(x86cpu, intel_idle_ids);
--
1.8.2.1.422.gdcd8c09
--
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/
2 idle patches for 3.9-rc7
Here are two stragglers for 3.9. Let me know if you have any troubles with them. thanks, Len Brown, Intel Open Source Technology Center -- 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] tools/power turbostat: additional Haswell CPU-id
From: Len Brown There is an additional HSW CPU-id, 0x46, which has C-states exactly like CPU-id 0x45. Signed-off-by: Len Brown --- tools/power/x86/turbostat/turbostat.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 6f3214e..321e066 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -1421,6 +1421,7 @@ int has_nehalem_turbo_ratio_limit(unsigned int family, unsigned int model) case 0x3C: /* HSW */ case 0x3F: /* HSW */ case 0x45: /* HSW */ + case 0x46: /* HSW */ return 1; case 0x2E: /* Nehalem-EX Xeon - Beckton */ case 0x2F: /* Westmere-EX Xeon - Eagleton */ @@ -1515,6 +1516,7 @@ void rapl_probe(unsigned int family, unsigned int model) case 0x3C: /* HSW */ case 0x3F: /* HSW */ case 0x45: /* HSW */ + case 0x46: /* HSW */ do_rapl = RAPL_PKG | RAPL_CORES | RAPL_GFX; break; case 0x2D: @@ -1754,6 +1756,7 @@ int is_snb(unsigned int family, unsigned int model) case 0x3C: /* HSW */ case 0x3F: /* HSW */ case 0x45: /* HSW */ + case 0x46: /* HSW */ return 1; } return 0; @@ -2276,7 +2279,7 @@ int main(int argc, char **argv) cmdline(argc, argv); if (verbose) - fprintf(stderr, "turbostat v3.2 February 11, 2013" + fprintf(stderr, "turbostat v3.3 March 15, 2013" " - Len Brown \n"); turbostat_init(); -- 1.8.2.1.422.gdcd8c09 -- 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.8-stable] esp4: fix error return code in esp_output()
From: Jonghwan Choi Date: Thu, 18 Apr 2013 07:33:19 +0900 > This patch looks like it should be in the 3.8-stable tree, should we > apply it? It's in my networking -stable queue, I wish you would check it instead of making more work for me replying to you to these kinds of emails. http://patchwork.ozlabs.org/bundle/davem/stable/?state=* 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/
[PATCH 3.8-stable] esp4: fix error return code in esp_output()
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Wei Yongjun "
commit 06848c10f720cbc20e3b784c0df24930b7304b93 upstream
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
Acked-by: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Jonghwan Choi
---
net/ipv4/esp4.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 3b4f0cd..4cfe34d 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -139,8 +139,6 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
/* skb is pure payload to encrypt */
- err = -ENOMEM;
-
esp = x->data;
aead = esp->aead;
alen = crypto_aead_authsize(aead);
@@ -176,8 +174,10 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
}
tmp = esp_alloc_tmp(aead, nfrags + sglists, seqhilen);
- if (!tmp)
+ if (!tmp) {
+ err = -ENOMEM;
goto error;
+ }
seqhi = esp_tmp_seqhi(tmp);
iv = esp_tmp_iv(aead, tmp, seqhilen);
--
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] net-sysfs: Add entry for nl80211 interface type
On Wed, 2013-04-17 at 15:06 -0700, Bing Zhao wrote: > Add a "wireless/nl80211_iftype" entry in the net device sysfs > file structure to indicate the mode of the wireless device so > it can be discovered easily from userspace. What's wrong with "iw dev", i.e. netlink/nl80211? johannes -- 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: [PATCHv3, RFC 31/34] thp: initial implementation of do_huge_linear_fault()
On 04/17/2013 07:38 AM, Kirill A. Shutemov wrote:
>> > Ugh. This is essentially a copy-n-paste of code in __do_fault(),
>> > including the comments. Is there no way to consolidate the code so that
>> > there's less duplication here?
> I've looked into it once again and it seems there's not much space for
> consolidation. Code structure looks very similar, but there are many
> special cases for thp: fallback path, pte vs. pmd, etc. I don't see how we
> can consolidate them in them in sane way.
> I think copy is more maintainable :(
I took the two copies, put them each in a file, changed some of the
_very_ trivial stuff to match (foo=1 vs foo=true) and diffed them.
They're very similar lengths (in lines):
185 __do_fault
197 do_huge_linear_fault
If you diff them:
1 file changed, 68 insertions(+), 56 deletions(-)
That means that of 185 lines in __do_fault(), 129 (70%) of them were
copied *VERBATIM*. Not similar in structure or appearance. Bit-for-bit
the same.
I took a stab at consolidating them. I think we could add a
VM_FAULT_FALLBACK flag to explicitly indicate that we need to do a
huge->small fallback, as well as a FAULT_FLAG_TRANSHUGE to indicate that
a given fault has not attempted to be handled by a huge page. If we
call __do_fault() with FAULT_FLAG_TRANSHUGE and we get back
VM_FAULT_FALLBACK or VM_FAULT_OOM, then we clear FAULT_FLAG_TRANSHUGE
and retry in handle_mm_fault().
I only went about 1/4 of the way in to __do_fault(). If went and spent
another hour or two, I'm pretty convinced I could push this even further.
Are you still sure you can't do _any_ better than a verbatim copy of 129
lines?
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7acc9dc..d408b5b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -879,6 +879,7 @@ static inline int page_mapped(struct page *page)
#define VM_FAULT_NOPAGE 0x0100 /* ->fault installed the pte, not return page */
#define VM_FAULT_LOCKED 0x0200 /* ->fault locked the returned page */
#define VM_FAULT_RETRY 0x0400 /* ->fault blocked, must retry */
+#define VM_FAULT_FALLBACK 0x0800 /* large page fault failed, fall back to small */
#define VM_FAULT_HWPOISON_LARGE_MASK 0xf000 /* encodes hpage index for large hwpoison */
diff --git a/mm/memory.c b/mm/memory.c
index 494526a..9aced3a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3229,6 +3229,40 @@ oom:
return VM_FAULT_OOM;
}
+static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, unsigned long addr)
+{
+ unsigned long haddr = address & HPAGE_PMD_MASK;
+
+ if (((vma->vm_start >> PAGE_SHIFT) & HPAGE_CACHE_INDEX_MASK) !=
+ (vma->vm_pgoff & HPAGE_CACHE_INDEX_MASK)) {
+ return false;
+ }
+ if (haddr < vma->vm_start || haddr + HPAGE_PMD_SIZE > vma->vm_end) {
+ return false;
+ }
+ return true;
+}
+
+static struct page *alloc_fault_page_vma(gfp_t flags, vm_area_struct *vma,
+ unsigned long address, unsigned int flags)
+{
+ int try_huge_pages = flags & FAULT_FLAG_TRANSHUGE;
+ unsigned long haddr = address & HPAGE_PMD_MASK;
+
+ if (try_huge_pages) {
+ return alloc_hugepage_vma(transparent_hugepage_defrag(vma),
+vma, haddr, numa_node_id(), 0);
+ }
+ return alloc_page_vma(flags, vma, address);
+}
+
+static inline void __user *align_fault_address(unsigned long address, unsigned int flags)
+{
+ if (flags & FAULT_FLAG_TRANSHUGE)
+ return (void __user *)address & HPAGE_PMD_MASK;
+ return (void __user *)(address & PAGE_MASK);
+}
+
/*
* __do_fault() tries to create a new page mapping. It aggressively
* tries to share with existing pages, but makes a separate copy if
@@ -3256,17 +3290,21 @@ static int __do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
struct vm_fault vmf;
int ret;
int page_mkwrite = 0;
+ int try_huge_pages = !!(flags & FAULT_FLAG_TRANSHUGE);
+
+ if (try_huge_pages && !transhuge_vma_suitable(vma)) {
+ return VM_FAULT_FALLBACK;
+ }
/*
* If we do COW later, allocate page befor taking lock_page()
* on the file cache page. This will reduce lock holding time.
*/
if ((flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) {
-
if (unlikely(anon_vma_prepare(vma)))
return VM_FAULT_OOM;
- cow_page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address);
+ cow_page = alloc_fault_page_vma(GFP_HIGHUSER_MOVABLE, vma, address);
if (!cow_page)
return VM_FAULT_OOM;
@@ -3277,7 +3315,7 @@ static int __do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
} else
cow_page = NULL;
- vmf.virtual_address = (void __user *)(address & PAGE_MASK);
+ vmf.virtual_address = align_fault_address(address, flags);
vmf.pgoff = pgoff;
vmf.flags = flags;
vmf.page = NULL;
@@ -3714,7 +3752,6 @@ int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
-
__set_current_state(TASK_RUNNING);
count_vm_event(PGFAULT);
@@ -3726,6 +3763,9 @@ int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
if (unlikely(is_vm_hugetlb_page(vma)))
[PATCH] net-sysfs: Add entry for nl80211 interface type
Add a "wireless/nl80211_iftype" entry in the net device sysfs
file structure to indicate the mode of the wireless device so
it can be discovered easily from userspace.
Signed-off-by: Paul Stewart
Signed-off-by: Bing Zhao
---
net/core/net-sysfs.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 7427ab5..454bd7f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -448,7 +449,24 @@ static struct attribute_group netstat_group = {
};
#if IS_ENABLED(CONFIG_WIRELESS_EXT) || IS_ENABLED(CONFIG_CFG80211)
+static ssize_t show_nl80211_iftype(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct net_device *netdev = to_net_dev(dev);
+ ssize_t ret = 0;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+ if (netdev->ieee80211_ptr)
+ ret = sprintf(buf, "%d\n", netdev->ieee80211_ptr->iftype);
+ rtnl_unlock();
+
+ return ret;
+}
+static DEVICE_ATTR(nl80211_iftype, S_IRUGO, show_nl80211_iftype, NULL);
+
static struct attribute *wireless_attrs[] = {
+ _attr_nl80211_iftype.attr,
NULL
};
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Erroneous double irq_eoi() on CPM IRQ in MPC8xx
irq_eoi() is already called by generic_handle_irq() so
it shall not be called a again
Signed-off-by: Christophe Leroy
Index: linux/arch/powerpc/platforms/8xx/m8xx_setup.c
===
--- linux/arch/powerpc/platforms/8xx/m8xx_setup.c (revision 4802)
+++ linux/arch/powerpc/platforms/8xx/m8xx_setup.c (working copy)
@@ -218,19 +218,12 @@
static void cpm_cascade(unsigned int irq, struct irq_desc *desc)
{
- struct irq_chip *chip;
- int cascade_irq;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ int cascade_irq = cpm_get_irq());
- if ((cascade_irq = cpm_get_irq()) >= 0) {
- struct irq_desc *cdesc = irq_to_desc(cascade_irq);
-
+ if (cascade_irq >= 0)
generic_handle_irq(cascade_irq);
- chip = irq_desc_get_chip(cdesc);
- chip->irq_eoi(>irq_data);
- }
-
- chip = irq_desc_get_chip(desc);
chip->irq_eoi(>irq_data);
}
--
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] Remove warning in efi_enter_virtual_mode V2
Some EFI BIOS stores BGRT data in the wrong place and some EFI based
BIOS also requires mapping of boot code/data when doing
efi_enter_virtual_mode.
Current code in efi_enter_virtual_mode maps both EFI_RUNTIME_MEMORY and
BIOS boot code/data.
This patch gives the option to switch off that behavior - if your BIOS
has neither BGRT - nor bugs that require mapping of EFI boot code/data
Removes the following warning when booting Linux with an EFI BIOS that
is bug free on IA32
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
Call Trace:
[] warn_slowpath_common+0x5f/0x80
[] ? __ioremap_caller+0x3d3/0x440
[] ? __ioremap_caller+0x3d3/0x440
[] warn_slowpath_null+0x1d/0x20
[] __ioremap_caller+0x3d3/0x440
[] ? get_usage_chars+0xfb/0x110
[] ? vprintk_emit+0x147/0x480
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] ioremap_cache+0x1a/0x20
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] efi_enter_virtual_mode+0x1e4/0x3de
[] start_kernel+0x286/0x2f4
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x12c/0x12f
---[ end trace 4eaa2a86a8e2da22 ]---
Mapping only memory EFI_RUNTIME_MEMORY is is consistent with the code in
arch/ia64/kernel/efi.c:efi_enter_virtual_mode();
Signed-off-by: Bryan O'Donoghue
---
Documentation/kernel-parameters.txt |4
arch/x86/platform/efi/efi.c | 14 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4609e81..faaa5cb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1856,6 +1856,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
noefi [X86] Disable EFI runtime services support.
+ noefi_virt_mapboot
+ [X86] Do not map EFI boot code/data when calling
+ efi_enter_virtual_mode().
+
noexec [IA-64]
noexec [X86]
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 5f2ecaf..64f98cd 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -88,6 +88,14 @@ static int __init setup_noefi(char *arg)
}
early_param("noefi", setup_noefi);
+static bool __initdata virt_mapboot = true;
+static int __init setup_noefi_virt_mapboot(char *arg)
+{
+ virt_mapboot = false;
+ return 0;
+}
+early_param("noefi_virt_mapboot", setup_noefi_virt_mapboot);
+
int add_efi_memmap;
EXPORT_SYMBOL(add_efi_memmap);
@@ -884,9 +892,9 @@ void __init efi_enter_virtual_mode(void)
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
+ if (!((md->attribute & EFI_MEMORY_RUNTIME) || (virt_mapboot &&
+ (md->type == EFI_BOOT_SERVICES_CODE ||
+md->type == EFI_BOOT_SERVICES_DATA
continue;
size = md->num_pages << EFI_PAGE_SHIFT;
--
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 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller wrote: > Patch 1/1 > > If hpsa is selected as the Smart Array driver cciss may try to load in the > kdump kernel. When this happens kdump fails and a core file cannot be created. > This patch prevents cciss from trying to load in this scenario. This effects > primarily older Smart Array controllers. > > ... > > --- a/drivers/block/cciss.c > +++ b/drivers/block/cciss.c > @@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const > struct pci_device_id *ent) > ctlr_info_t *h; > unsigned long flags; > > + /* > + * if this is the kdump kernel and the user has set the flags to > + * use hpsa rather than cciss just bail > + */ > + if ((reset_devices) && (cciss_allow_hpsa == 1)) > + return -ENODEV; OK, wazzup. That's the only occurrence of the symbol "cciss_allow_hpsa" in Linux and needless to say, the compiler laughed at me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
On Wed, Apr 17, 2013 at 10:52 PM, Timur Tabi wrote: > On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely > wrote: >> >>> I really preciate if you can spend some times to review this patch. >> >> Applied, thanks. > > Pff. Why do I bother? Relax Timur: http://git.secretlab.ca/?p=linux.git;a=commitdiff;h=b855f16b05a697ac1863adabe99bfba56e6d3199 g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] binfmt_elf: PIE: make PF_RANDOMIZE check comment more accurate
The comment I originally added in a3defbe5c337db ("binfmt_elf: fix PIE
execution with randomization disabled") is not really 100% accurate --
sysctl is not the only way how PF_RANDOMIZE could be forcibly unset in
runtime.
Another option of course is direct modification of personality flags (i.e.
running through setarch wrapper).
Make the comment more explicit and accurate.
Signed-off-by: Jiri Kosina
---
fs/binfmt_elf.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..7e533c0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -803,7 +803,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
* follow the loader, and is not movable. */
#ifdef CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE
/* Memory randomization might have been switched off
-* in runtime via sysctl.
+* in runtime via sysctl or explicit setting of
+* personality flags.
* If that is the case, retain the original non-zero
* load_bias value in order to establish proper
* non-randomized mappings.
--
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/
Re: [PATCH] Remove warning in efi_enter_virtual_mode
On 17/04/13 15:06, Matt Fleming wrote:
(Cc'ing some more folks)
On 16/04/13 16:58, Bryan O'Donoghue wrote:
This warning is caused by efi_enter_virtual_mode mapping memory marked
as !EFI_RUNTIME_MEMORY. The reason this memory is being mapped is to
work around buggy code that stores an ACPI object called the Boot
Graphics Resource Table - BGRT in memory of type EfiBootServices*.
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
Call Trace:
[] warn_slowpath_common+0x5f/0x80
[] ? __ioremap_caller+0x3d3/0x440
[] ? __ioremap_caller+0x3d3/0x440
[] warn_slowpath_null+0x1d/0x20
[] __ioremap_caller+0x3d3/0x440
[] ? get_usage_chars+0xfb/0x110
[] ? vprintk_emit+0x147/0x480
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] ioremap_cache+0x1a/0x20
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] efi_enter_virtual_mode+0x1e4/0x3de
[] start_kernel+0x286/0x2f4
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x12c/0x12f
---[ end trace 4eaa2a86a8e2da22 ]---
The warning is telling you that someone is trying to ioremap RAM, which
is bad. It's not specifically an issue with the bgrt image, it's just
that said object happens to occupy an EfiBootServicesData region which
isn't mapped by the direct kernel mapping on i386.
I understand that.
In my mind the only memory that is relevant to efi_enter_virtual_mode is
memory that the BIOS has marked as EFI_RUNTIME_SERVICE
md->attribute & 0x8000_
I couldn't quite understand why the code in
arch/x86/platform/efi/efi.c:enter_virtual_mode() looks like this
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
continue;
While the code in
arch/ia64/kernel/efi.c:enter_virtual_mode
for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
md = p;
if (md->attribute & EFI_MEMORY_RUNTIME) {
The ia64 version is consistent with the standard - but obviously isn't
accounting for the work-around implemented to retrieve the BGRT on ia32.
Looking at the commit message associated with
arch/x86/platform/efi/efi-bgrt.c
It's pretty obvious the mapping of boot code/data was done to facilitate
BGRT.
Since the EFI memory map I'm using is clean - below - there's no reason
for us to map the boot code/data.
Most (all?) boot loaders mark EFI_BOOT_SERVICES_{CODE,DATA} as E820_RAM,
which is why ioremap() complained about you trying to ioremap() a page
of RAM.
But they aught to. It's entirely legitimate for the run-time to reclaim
this memory - since after ExitBootServices() - none of the code/data
inside of EFI_BOOT_SERVICES is of any use.
Caveat being the work-around that was done for BGRT.
They do this because after efi_free_boot_services() we want
these regions to be available for general allocation.
Agree.
On x86-64 you rarely hit the ioremap() path because all RAM regions are
mapped by the kernel direct mapping, e.g __va() works on those
addresses. On i386, with its reduced virtual address space, it's much
more likely that those addresses are not part of the direct mapping, and
so this is the chunk of code that causes problems in
efi_enter_virtual_mode(),
start_pfn = PFN_DOWN(md->phys_addr);
end_pfn = PFN_UP(end);
if (pfn_range_is_mapped(start_pfn, end_pfn)) {
va = __va(md->phys_addr);
if (!(md->attribute& EFI_MEMORY_WB))
efi_memory_uc((u64)(unsigned long)va, size);
} else
va = efi_ioremap(md->phys_addr, size,
md->type, md->attribute);
Yes it fails sanity checking in efi_ioremap::__ioremap_caller on an
"is_ram()" call.
What we probably need is an i386-specific implementation of
efi_ioremap() that checks to see whether we're mapping a RAM region. I
thought of maybe using the kmap_high() functions, but I don't think
repeated calls to the kmap*() functions are guaranteed to provide
consecutive virtual addresses, and I doubt free_bootmem() (called from
efi_free_boot_services()) understands kmap'd addresses.
That's one solution - you'd need to make the i386::efi_ioremap() aware
of the BGRT work-around.
Presumably this work-around is also required on ia64 too.
Maybe we should hot-add the EFI_BOOT_SERVICES_* regions once we've
finished with them and only then mark them as RAM?
x86 folks? Halp?
On systems that do not have a BGRT object, there's no reason to map this
memory in efi_enter_virtual_mode. This patch searches for the BGRT
object and if found - will continue to map the boot services memory,
else only memory with
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, 18 Mar 2013 15:50:30 +0100 Nicolas Schichan wrote: > Architecture must select HAVE_SECCOMP_FILTER_JIT and implement > seccomp_jit_compile() and seccomp_jit_free() if they intend to support > jitted seccomp filters. > > struct seccomp_filter has been moved to to make its > content available to the jit compilation code. > > In a way similar to the net BPF, the jit compilation code is expected > to updates struct seccomp_filter.bpf_func pointer to the generated > code. > This patch is killing me. > --- a/include/linux/seccomp.h > +++ b/include/linux/seccomp.h > @@ -6,6 +6,7 @@ > #ifdef CONFIG_SECCOMP > > #include > +#include > #include In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 "make clean; make allmodconfig; make". I had a few slashes at fixing it but got all frustrated. -- 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 v7 0/21] sched: power aware scheduling
On 04/12/2013 12:48 PM, Mike Galbraith wrote: > On Fri, 2013-04-12 at 18:23 +0200, Borislav Petkov wrote: >> On Fri, Apr 12, 2013 at 04:46:50PM +0800, Alex Shi wrote: >>> Thanks a lot for comments, Len! >> >> AFAICT, you kinda forgot to answer his most important question: >> >>> These numbers suggest that this patch series simultaneously >>> has a negative impact on performance and energy required >>> to retire the workload. Why do it? > > Hm. When I tested AIM7 compute on a NUMA box, there was a marked > throughput increase at the low to moderate load end of the test spectrum > IIRC. Fully repeatable. There were also other benefits unrelated to > power, ie mitigation of the evil face of select_idle_sibling(). I > rather liked what I saw during ~big box test-drive. > > (just saying there are other aspects besides joules in there) Mike, Can you re-run your AIM7 measurement with turbo-mode and HT-mode disabled, and then independently re-enable them? If you still see the performance benefit, then that proves that the scheduler hacks are not about tricking into turbo mode, but something else. If the performance gains *are* about interactions with turbo-mode, then perhaps what we should really be doing here is making the scheduler explicitly turbo-aware? Of course, that begs the question of how the scheduler should be aware of cpufreq in general... thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely wrote: > >> I really preciate if you can spend some times to review this patch. > > Applied, thanks. Pff. Why do I bother? -- 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: How to override GMA500 resolution set by BIOS?
On Wed, Apr 17, 2013 at 7:39 PM, Marcin Szewczyk wrote: > Hello, > > I've got a problem with GMA500 on my EVOC EC2-1711. The graphics > adapter's resolution is set by selecting an option in BIOS but I would > like to override it. Can kernel or Xorg do this? > > There are two modes "almost" right for an 800x600 16bit LVDS screen I > have. The first one is 800x600 but in 24bit LVDS mode, so colors are > mangled. The second one is 800x480 16bit -- colors are right, but the > screen cuts the image at line 480. > > I've tried video=, overwriting modes via patched 915resolution, vga= and > Xorg modesetting driver. Nothing works. > > Does anyone know if it's possible to override the mode? Hi Marcin, I haven't played much with 16 bpp on the gma500 kernel driver but at the moment it seems broken. I added a screen section to xorg.conf with DefaultDepth 16 running the fbdev driver. That, at least tries to do the right thing but gma500 fails in setting it up. On the other hand, you managed to set 800x480 at 16bbp. Have you tried the vesafb driver? Might do a better job. -Patrik Jakobsson -- 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] watchdog: Add hook for kicking in kdump path
Don Zickus writes: > A common problem with kdump is that during the boot up of the > second kernel, the hardware watchdog times out and reboots the > machine before a vmcore can be captured. > > Instead of tellling customers to disable their hardware watchdog > timers, I hacked up a hook to put in the kdump path that provides > one last kick before jumping into the second kernel. > > The assumption is the watchdog timeout is at least 10-30 seconds > long, enough to get the second kernel to userspace to kick the watchdog > again, if needed. Why not double the watchdog timeout? and/or pet the watchdog a little more frequently. This is the least icky hook I have seen proposed to be put on the kexec on panic path, but I still suspect this may reduce the ability to take a crash dump. What happens if it was the watchdog timer that panic'd for example. Eric -- 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: [tpmdd-devel] [PATCH 1/1] TPM: STMicroelectronics st33 driver SPI
Hi Matthias,
On Fri, Apr 12, 2013 at 10:44:11AM +0200, Matthias Leblanc wrote:
> From: Mathias Leblanc
>
> * STMicroelectronics version 1.2.0, Copyright (C) 2010
> * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
> * This is free software, and you are welcome to redistribute it
> * under certain conditions.
>
> This is the driver for TPM chip from ST Microelectronics.
>
> If you have a TPM security chip from STMicroelectronics working with
> an SPI, in menuconfig or .config choose the tpm driver on
> device --> tpm and activate the protocol of your choice before compiling
> the kernel.
> The driver will be accessible from within Linux.
>
> Tested on linux x86/x64 and beagleboard REV B & XM REV C
>
> Signed-off-by: Mathias Leblanc
> ---
> drivers/char/tpm/Kconfig | 10 +
> drivers/char/tpm/Makefile|1 +
> drivers/char/tpm/tpm_spi_stm_st33.c | 1116
> ++
> drivers/char/tpm/tpm_spi_stm_st33.h | 75 +++
> include/linux/spi/tpm_spi_stm_st33.h | 44 ++
> 7 files changed, 1246 insertions(+), 161 deletions(-)
> delete mode 100644 .gitignore
> delete mode 100644 REPORTING-BUGS
> create mode 100644 drivers/char/tpm/tpm_spi_stm_st33.c
> create mode 100644 drivers/char/tpm/tpm_spi_stm_st33.h
> create mode 100644 include/linux/spi/tpm_spi_stm_st33.h
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index dbfd564..2fc1254 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -91,4 +91,14 @@ config TCG_ST33_I2C
> To compile this driver as a module, choose M here; the module will be
> called tpm_stm_st33_i2c.
>
> +config TCG_ST33_SPI
> + tristate "STMicroelectronics ST33 SPI"
> + depends on SPI
> + depends on GPIOLIB
> + ---help---
> + If you have a TPM security chip from STMicroelectronics working with
> + an SPI bus say Yes and it will be accessible from within Linux.
> + To compile this driver as a module, choose M here; the module will be
> + called tpm_stm_st33_spi.
> +
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index a3736c9..a1db3dd 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
> obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
> obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
> obj-$(CONFIG_TCG_ST33_I2C) += tpm_i2c_stm_st33.o
> +obj-$(CONFIG_TCG_ST33_SPI) += tpm_spi_stm_st33.o
> diff --git a/drivers/char/tpm/tpm_spi_stm_st33.c
> b/drivers/char/tpm/tpm_spi_stm_st33.c
> new file mode 100644
> index 000..9462f7c
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_spi_stm_st33.c
> @@ -0,0 +1,1116 @@
> +/*
> + * STMicroelectronics TPM SPI Linux driver for TPM ST33ZP24
> + * Copyright (C) 2009, 2010 STMicroelectronics
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * STMicroelectronics version 1.2.0, Copyright (C) 2010
> + * STMicroelectronics comes with ABSOLUTELY NO WARRANTY.
> + * This is free software, and you are welcome to redistribute it
> + * under certain conditions.
> + *
> + * @Author: Christophe RICARD tpmsupp...@st.com
> + *
> + * @File: tpm_stm_st33_spi.c
> + *
> + * @Synopsis:
> + * 09/15/2010: First shot driver tpm_tis driver for lpc is
> + * used as model.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This looks unused, please remove.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
Is there a need for this header to live in linux/spi? You should move
it into the local header.
> +#include "tpm.h"
> +
> +#include "tpm_spi_stm_st33.h"
> +
> +#ifdef DEBUG
> +#define FUNC_ENTER() pr_info("%s\n", __func__)
> +#else
> +#define FUNC_ENTER()do {} while (0)
> +#endif
Please remove FUNC_ENTER().
> +enum stm33zp24_access {
> + TPM_ACCESS_VALID = 0x80,
> + TPM_ACCESS_ACTIVE_LOCALITY = 0x20,
> + TPM_ACCESS_REQUEST_PENDING = 0x04,
> + TPM_ACCESS_REQUEST_USE = 0x02,
> +};
> +
> +enum stm33zp24_status {
> + TPM_STS_VALID =
Re: [PATCH v3] watchdog: Add hook for kicking in kdump path
On Wed, Apr 17, 2013 at 05:19:56PM -0400, Don Zickus wrote:
> A common problem with kdump is that during the boot up of the
> second kernel, the hardware watchdog times out and reboots the
> machine before a vmcore can be captured.
>
> Instead of tellling customers to disable their hardware watchdog
> timers, I hacked up a hook to put in the kdump path that provides
> one last kick before jumping into the second kernel.
>
> The assumption is the watchdog timeout is at least 10-30 seconds
> long, enough to get the second kernel to userspace to kick the watchdog
> again, if needed.
>
> Of course kdump is usually executed on a panic path, so grabbing the
> watchdog mutexes to communicate with the hardware won't work. For now,
> I use trylock, otherwise fail.
>
> I have tested this with a machine using iTCO_wdt and the 'watchdog' app.
> The extra kicked happened as expected.
>
> v2: based on feedback, implemented a linked list of watchdog references.
> added trylock in watchdog_ping and used that function for kicking.
> renamed export function to be more generic.
>
> v3: small cleanups, remove mutex_safe variable from EXPORT_SYMBOL
>
> Signed-off-by: Don Zickus
I know, I am nitpicking. Just a couple of small issues.
> ---
> drivers/watchdog/watchdog_dev.c | 74 +++---
> include/linux/watchdog.h|9 +
> kernel/kexec.c |6 +++
> 3 files changed, 83 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 08b48bb..52cb465 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -49,6 +49,16 @@ static dev_t watchdog_devt;
> /* the watchdog device behind /dev/watchdog */
> static struct watchdog_device *old_wdd;
>
> +/* link list of all watchdog devices */
> +struct watchdog_list {
> + spinlock_t lock;
> + struct list_head head;
> +};
> +static struct watchdog_list wdlist = {
> + .lock = __SPIN_LOCK_UNLOCKED(wdlist.lock),
> + .head = LIST_HEAD_INIT(wdlist.head),
> +};
> +
> /*
> * watchdog_ping: ping the watchdog.
> * @wddev: the watchdog device to ping
> @@ -59,11 +69,18 @@ static struct watchdog_device *old_wdd;
> * We only ping when the watchdog device is running.
> */
>
> -static int watchdog_ping(struct watchdog_device *wddev)
> +static int watchdog_ping(struct watchdog_device *wddev, bool mutex_safe)
> {
> int err = 0;
>
> - mutex_lock(>lock);
> + if (mutex_safe) {
> + mutex_lock(>lock);
> + } else {
> + if (!mutex_trylock(>lock)) {
> + pr_warn("watchdog%d: Unable to lock mutex\n",
> wddev->id);
> + return -EAGAIN;
> + }
> + }
>
> if (test_bit(WDOG_UNREGISTERED, >status)) {
> err = -ENODEV;
> @@ -83,6 +100,38 @@ out_ping:
> return err;
> }
>
> +/**
> + * watchdog_kick_all: kick all the watchdogs
> + *
> + * There are times when the kernel needs to kick all the
> + * watchdogs at once without the use of references. For
> + * example in the kdump path, when the kernel is about
> + * to jump into the second kernel.
> + *
> + * The 'false' variable is for contextes that can not
> + * sleep, therefore try to kick the watchdog with trylock
> + * instead.
The variable no longer exists.
> + *
> + * Walk the link list locklessly using RCU to handle various
> + * contexts this could be called in. Should support irq and
> + * NMI contexts correctly.
> + */
> +
> +void watchdog_kick_all(void)
> +{
> + struct watchdog_device *wddev;
> +
> + rcu_read_lock();
> +
> + list_for_each_entry_rcu(wddev, , list)
> + watchdog_ping(wddev, false);
> +
> + rcu_read_unlock();
> +
> + return;
Unnecessary return statement.
> +}
> +EXPORT_SYMBOL_GPL(watchdog_kick_all);
> +
> /*
> * watchdog_start: wrapper to start the watchdog.
> * @wddev: the watchdog device to start
> @@ -314,7 +363,7 @@ static ssize_t watchdog_write(struct file *file, const
> char __user *data,
> }
>
> /* someone wrote to us, so we send the watchdog a keepalive ping */
> - watchdog_ping(wdd);
> + watchdog_ping(wdd, true);
>
> return len;
> }
> @@ -370,7 +419,7 @@ static long watchdog_ioctl(struct file *file, unsigned
> int cmd,
> case WDIOC_KEEPALIVE:
> if (!(wdd->info->options & WDIOF_KEEPALIVEPING))
> return -EOPNOTSUPP;
> - watchdog_ping(wdd);
> + watchdog_ping(wdd, true);
> return 0;
> case WDIOC_SETTIMEOUT:
> if (get_user(val, p))
> @@ -381,7 +430,7 @@ static long watchdog_ioctl(struct file *file, unsigned
> int cmd,
> /* If the watchdog is active then we send a keepalive ping
>* to make sure that the watchdog keep's running (and if
>* possible that it takes the
Re: Device driver memory 'mmap()' function helper cleanup
On Wed, Apr 17, 2013 at 2:28 PM, Arnd Bergmann wrote: > > There is a separate check for the physical address that gets > mapped in hpet_mmap: Ahh, right you are. The earlier check for PAGE_SIZE's mapping and zero offset is indeed superfluous. Linus -- 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/
