Re: [PATCH 05/13] overlayfs: add statfs support

[Ben Hutchings]

On Thu, 2012-08-30 at 00:48 +0200, Miklos Szeredi wrote:
> Ben Hutchings  writes:
> 
> > On Wed, Aug 15, 2012 at 05:48:12PM +0200, Miklos Szeredi wrote:
> >> From: Andy Whitcroft 
> >> 
> >> Add support for statfs to the overlayfs filesystem.  As the upper layer
> >> is the target of all write operations assume that the space in that
> >> filesystem is the space in the overlayfs.  There will be some inaccuracy as
> >> overwriting a file will copy it up and consume space we were not expecting,
> >> but it is better than nothing.
> >> 
> >> Use the upper layer dentry and mount from the overlayfs root inode,
> >> passing the statfs call to that filesystem.
> > [...] 
> >> +/**
> >> + * ovl_statfs
> >> + * @sb: The overlayfs super block
> >> + * @buf: The struct kstatfs to fill in with stats
> >> + *
> >> + * Get the filesystem statistics.  As writes always target the upper layer
> >> + * filesystem pass the statfs to the same filesystem.
> >> + */
> >> +static int ovl_statfs(struct dentry *dentry, struct kstatfs *buf)
> >> +{
> >> +  struct dentry *root_dentry = dentry->d_sb->s_root;
> >> +  struct path path;
> >> +  ovl_path_upper(root_dentry, );
> >> +
> >> +  if (!path.dentry->d_sb->s_op->statfs)
> >> +  return -ENOSYS;
> >> +  return path.dentry->d_sb->s_op->statfs(path.dentry, buf);
> >> +}
> > [...]
> >
> > In case f_namelen differs between the upper and lower filesystems, you
> > need to return the greater of the two.
> 
> Maybe.  I've never seen any app use f_namelen for anything useful.
[...]

If I'm not mistaken, glibc uses it to implement pathconf(_PC_NAME_MAX),
which may be used by applications in conjunction with readdir_r().

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


signature.asc
Description: This is a digitally signed message part

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

a bunch of scattered fixes ati/intel/nouveau, couple of core ones,
nothing too shocking or different.

Dave.

The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:

  Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b:

  drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S (2012-08-30 
14:14:12 +1000)


Alex Deucher (5):
  drm/radeon: don't disable plls that are in use by other crtcs
  drm/radeon/atom: rework DIG modesetting on DCE3+
  drm/radeon/atom: powergating fixes for DCE6
  drm/radeon: rework panel mode setup
  drm/radeon: fix dig encoder selection on DCE61

Ben Skeggs (1):
  drm/nvc0/copy: check PUNITS to determine which copy engines are disabled

Calvin Walton (1):
  i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

Chris Wilson (1):
  drm/i915: Use the correct size of the GTT for placing the per-process 
entries

Christian König (1):
  drm/radeon: fix double free in radeon_gpu_reset

Dave Airlie (3):
  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Forest Bond (1):
  gma500: Consider CRTC initially active.

Jakob Bornecrantz (1):
  drm: Check for invalid cursor flags

Jerome Glisse (1):
  drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

Marek Olšák (3):
  drm/radeon: fix reading CB_COLORn_MASK from the CS
  drm/radeon: initialize tracked CS state
  drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

Paul Menzel (1):
  drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

Vijay Purushothaman (1):
  drm/i915: fix color order for BGR formats on IVB

Ville Syrjälä (1):
  drm: Initialize object type when using DRM_MODE() macro

Xu, Anhua (1):
  drm/i915: fix wrong order of parameters in port checking functions

 drivers/gpu/drm/drm_crtc.c |2 +-
 drivers/gpu/drm/drm_edid.c |3 +
 drivers/gpu/drm/gma500/psb_intel_display.c |3 +
 drivers/gpu/drm/i915/i915_gem_gtt.c|2 +-
 drivers/gpu/drm/i915/intel_display.c   |   12 +--
 drivers/gpu/drm/i915/intel_lvds.c  |8 ++
 drivers/gpu/drm/i915/intel_sprite.c|4 +-
 drivers/gpu/drm/nouveau/nouveau_state.c|6 +-
 drivers/gpu/drm/radeon/atombios_crtc.c |   36 ---
 drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++---
 drivers/gpu/drm/radeon/atombios_encoders.c |  140 +++-
 drivers/gpu/drm/radeon/r600_cs.c   |   30 +-
 drivers/gpu/drm/radeon/r600d.h |8 ++
 drivers/gpu/drm/radeon/radeon_device.c |5 +-
 drivers/gpu/drm/radeon/radeon_drv.c|3 +-
 drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
 include/drm/drm_crtc.h |3 +-
 include/drm/drm_mode.h |5 +-
 18 files changed, 174 insertions(+), 126 deletions(-)

[PATCH] MAINTAINERS: fix TXT maintainer list and source repo path

[gang . wei]

From: Gang Wei 

Signed-off-by: Gang Wei 
---
 MAINTAINERS |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..987ad0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3666,11 +3666,12 @@ F:  Documentation/networking/README.ipw2200
 F: drivers/net/wireless/ipw2x00/
 
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
-M: Joseph Cihula 
+M: Richard L Maliszewski 
+M: Gang Wei 
 M: Shane Wang 
 L: tboot-de...@lists.sourceforge.net
 W: http://tboot.sourceforge.net
-T: Mercurial http://www.bughost.org/repos.hg/tboot.hg
+T: Mercurial http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot
 S: Supported
 F: Documentation/intel_txt.txt
 F: include/linux/tboot.h
-- 
1.7.7.6

--
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: tegra: moving phy driver into drivers directory

[Venu Byravarasu]

> -Original Message-
> From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra-
> ow...@vger.kernel.org] On Behalf Of Stephen Warren
> Sent: Wednesday, August 29, 2012 11:01 PM
> To: Venu Byravarasu
> Cc: ccr...@android.com; o...@lixom.net; li...@arm.linux.org.uk;
> st...@rowland.harvard.edu; gre...@linuxfoundation.org; ba...@ti.com;
> linux-kernel@vger.kernel.org; linux-te...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: tegra: moving phy driver into drivers directory
> 
> On 08/28/12 22:17, Venu Byravarasu wrote:
> > Stephen Warren wrote at Tuesday, August 28, 2012 7:37 PM:
> >> On 08/28/2012 02:32 AM, Venu Byravarasu wrote:
> >>> In order to keep up with the USB driver files organization,
> >>> moving USB phy driver from mach-tegra to drivers/USB directory.
> >>>
> >>> Signed-off-by: Venu Byravarasu 
> >>
> >>> diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-
> >> tegra/devices.c
> >>
> >>> -struct tegra_ulpi_config tegra_ehci2_ulpi_phy_config = {
> >>> - .reset_gpio = -1,
> >>> - .clk = "cdev2",
> >>> -};
> >>> -
> >>>   struct tegra_ehci_platform_data tegra_ehci1_pdata = {
> >>>   .operating_mode = TEGRA_USB_OTG,
> >>>   .power_down_on_bus_suspend = 1,
> >>> @@ -450,7 +444,7 @@ struct tegra_ehci_platform_data
> tegra_ehci1_pdata
> >> = {
> >>>   };
> >>>
> >>>   struct tegra_ehci_platform_data tegra_ehci2_pdata = {
> >>> - .phy_config = _ehci2_ulpi_phy_config,
> >>> + .phy_config = NULL,
> >>
> >> The PHY driver checks that field isn't NULL, and fails if it is:
> >>
> >>> struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int
> >> instance,
> >>>  void __iomem *regs, void *config, enum tegra_usb_phy_mode
> >> phy_mode)
> >>> {
> >> ...
> >>>  phy->config = config;
> >>>  phy->mode = phy_mode;
> >>>
> >>>  if (!phy->config) {
> >>>  if (phy_is_ulpi(phy)) {
> >>>  pr_err("%s: ulpi phy configuration missing", 
> >>> __func__);
> >>>  err = -EINVAL;
> >>>  goto err0;
> >>
> >> So, this change will completely break ULPI support, which currently
> >> works fine. So, NAK.
> >
> > My initial plan was to add support for phy interfaces one by one.
> > As part of that thought of UTMI only support at first and then add
> > ULPI and HSIC in next patches.
> > However as you were mentioning that it is not correct way, will
> > push ULPI & UTMI support at once in next patches.
> 
> But with the existing code, both ULPI and UTMI work. This patch breaks
> something that already works.
> 
> >> I also plan on deleting devices.[ch] in kernel 3.7, and moving the USB
> >> platform data into board-dt-tegra20.c, since that's the only place it's
> >> used right now. So, this patch would conflict with that rather badly. I
> >> just posted the patches for that to the linux-tegra mailing list last
> >> night. Do you have better proposals for that? Perhaps usb_phy.c should
> >> set phy->config to _default in a similar fashion to how it works
> >> for UTMI; that would remove some of the coupling between the changes.
> >>
> >> BTW, in your response to Felipe, you said...
> >>
> >>> Thanks Felipe for your comments.
> >>> Created a patch to separate out phy related stuff to phy.h with you as a
> >> reviewer.
> >>> Plz let me know your comments.
> >>
> >> ... where is that patch?
> >
> > Plz see https://lkml.org/lkml/2012/8/28/58
> 
> Doesn't that link point at the patch I replied to?

Sorry, by mistake I sent the wrong one.
Here is the correct one: https://lkml.org/lkml/2012/8/29/40  

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

Which disk is ata4?

[Andy Lutomirski]

One of my disks went out to lunch for a while.  Logs below.

Which one is it?  The only useful thing in /sys/class/ata_port/ata4 is
the device symlink, which points at
/sys/devices/pci:00/:00:1f.2/ata4.  That, in turn, has an
ata_port directory (contains nothing I don't already know) and a link4
directory.  The ata_link directory is unhelpful, as is
/sys/devices/pci:00/:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0.

Taking a leap of faith, /sys/devices/pci:00/:00:1f.2 contains
ata1-6 and host0-5.  So maybe ata4 is host3.  Following lots of
symlinks through host3 leads me to the block device sdd.  Maybe that's
correct?  I'm really not sure.  Am I missing something obvious?

I even tried looking for symlinks the other way, like this:

/sys$ find -type l -exec echo -n {} ' ' \; -exec readlink {} \; |grep ata4
./devices/pci:00/:00:1f.2/ata4/ata_port/ata4/subsystem
../../../../../../class/ata_port
./devices/pci:00/:00:1f.2/ata4/ata_port/ata4/device  ../../../ata4
./devices/pci:00/:00:1f.2/ata4/link4/ata_link/link4/subsystem
../../../../../../../class/ata_link
./devices/pci:00/:00:1f.2/ata4/link4/ata_link/link4/device
../../../link4
./devices/pci:00/:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0/subsystem
 ../../../../../../../../class/ata_device
./devices/pci:00/:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0/device
 ../../../dev4.0
./class/ata_link/link4
../../devices/pci:00/:00:1f.2/ata4/link4/ata_link/link4
./class/ata_port/ata4  ../../devices/pci:00/:00:1f.2/ata4/ata_port/ata4
./class/ata_device/dev4.0
../../devices/pci:00/:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0

No luck.

[784786.047673] ata4.00: exception Emask 0x10 SAct 0x7800 SErr 0x0
action 0x6 frozen
[784786.047707] ata4.00: irq_stat 0x0800, interface fatal error
[784786.047730] ata4.00: failed command: READ FPDMA QUEUED
[784786.047752] ata4.00: cmd 60/40:58:80:a9:48/00:00:86:00:00/40 tag
11 ncq 32768 in
[784786.047753]  res c0/00:40:80:15:8d/00:00:86:00:00/40 Emask
0x12 (ATA bus error)
[784786.047805] ata4.00: status: { Busy }
[784786.047819] ata4.00: failed command: READ FPDMA QUEUED
[784786.047840] ata4.00: cmd 60/40:60:80:aa:48/00:00:86:00:00/40 tag
12 ncq 32768 in
[784786.047841]  res c0/00:40:80:15:8d/00:00:86:00:00/40 Emask
0x12 (ATA bus error)
[784786.047893] ata4.00: status: { Busy }
[784786.047907] ata4.00: failed command: READ FPDMA QUEUED
[784786.047928] ata4.00: cmd 60/40:68:c0:aa:48/00:00:86:00:00/40 tag
13 ncq 32768 in
[784786.047929]  res c0/00:40:80:15:8d/00:00:86:00:00/40 Emask
0x12 (ATA bus error)
[784786.047981] ata4.00: status: { Busy }
[784786.047996] ata4.00: failed command: READ FPDMA QUEUED
[784786.048016] ata4.00: cmd 60/40:70:00:ab:48/00:00:86:00:00/40 tag
14 ncq 32768 in
[784786.048017]  res c0/00:40:80:15:8d/00:00:86:00:00/40 Emask
0x12 (ATA bus error)
[784786.048067] ata4.00: status: { Busy }
[784786.048085] ata4: hard resetting link
[784786.365119] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[784786.380854] ata4.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[784786.380860] ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY
FREEZE LOCK) filtered out
[784786.380864] ata4.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE
CONFIGURATION OVERLAY) filtered out
[784786.382279] ata4.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[784786.382283] ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY
FREEZE LOCK) filtered out
[784786.382287] ata4.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE
CONFIGURATION OVERLAY) filtered out
[784786.382747] ata4.00: configured for UDMA/133
[784786.382761] ata4: EH complete

--Andy
--
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 v6 1/1] ieee802154: MRF24J40 driver

[Alan Ott]

Driver for the Microchip MRF24J40 802.15.4 WPAN module.

Signed-off-by: Alan Ott 
---
 drivers/ieee802154/Kconfig|   11 +
 drivers/ieee802154/Makefile   |1 +
 drivers/ieee802154/mrf24j40.c |  767 +
 3 files changed, 779 insertions(+), 0 deletions(-)
 create mode 100644 drivers/ieee802154/mrf24j40.c

diff --git a/drivers/ieee802154/Kconfig b/drivers/ieee802154/Kconfig
index 1fc4eef..08ae465 100644
--- a/drivers/ieee802154/Kconfig
+++ b/drivers/ieee802154/Kconfig
@@ -34,3 +34,14 @@ config IEEE802154_AT86RF230
 depends on IEEE802154_DRIVERS && MAC802154
 tristate "AT86RF230/231 transceiver driver"
 depends on SPI
+
+config IEEE802154_MRF24J40
+   tristate "Microchip MRF24J40 transceiver driver"
+   depends on IEEE802154_DRIVERS && MAC802154
+   depends on SPI
+   ---help---
+ Say Y here to enable the MRF24J20 SPI 802.15.4 wireless
+ controller.
+
+ This driver can also be built as a module. To do so, say M here.
+ the module will be called 'mrf24j40'.
diff --git a/drivers/ieee802154/Makefile b/drivers/ieee802154/Makefile
index 4f4371d..abb0c08 100644
--- a/drivers/ieee802154/Makefile
+++ b/drivers/ieee802154/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_IEEE802154_FAKEHARD) += fakehard.o
 obj-$(CONFIG_IEEE802154_FAKELB) += fakelb.o
 obj-$(CONFIG_IEEE802154_AT86RF230) += at86rf230.o
+obj-$(CONFIG_IEEE802154_MRF24J40) += mrf24j40.o
diff --git a/drivers/ieee802154/mrf24j40.c b/drivers/ieee802154/mrf24j40.c
new file mode 100644
index 000..0e53d4f
--- /dev/null
+++ b/drivers/ieee802154/mrf24j40.c
@@ -0,0 +1,767 @@
+/*
+ * Driver for Microchip MRF24J40 802.15.4 Wireless-PAN Networking controller
+ *
+ * Copyright (C) 2012 Alan Ott 
+ *Signal 11 Software
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* MRF24J40 Short Address Registers */
+#define REG_RXMCR0x00  /* Receive MAC control */
+#define REG_PANIDL   0x01  /* PAN ID (low) */
+#define REG_PANIDH   0x02  /* PAN ID (high) */
+#define REG_SADRL0x03  /* Short address (low) */
+#define REG_SADRH0x04  /* Short address (high) */
+#define REG_EADR00x05  /* Long address (low) (high is EADR7) */
+#define REG_TXMCR0x11  /* Transmit MAC control */
+#define REG_PACON0   0x16  /* Power Amplifier Control */
+#define REG_PACON1   0x17  /* Power Amplifier Control */
+#define REG_PACON2   0x18  /* Power Amplifier Control */
+#define REG_TXNCON   0x1B  /* Transmit Normal FIFO Control */
+#define REG_TXSTAT   0x24  /* TX MAC Status Register */
+#define REG_SOFTRST  0x2A  /* Soft Reset */
+#define REG_TXSTBL   0x2E  /* TX Stabilization */
+#define REG_INTSTAT  0x31  /* Interrupt Status */
+#define REG_INTCON   0x32  /* Interrupt Control */
+#define REG_RFCTL0x36  /* RF Control Mode Register */
+#define REG_BBREG1   0x39  /* Baseband Registers */
+#define REG_BBREG2   0x3A  /* */
+#define REG_BBREG6   0x3E  /* */
+#define REG_CCAEDTH  0x3F  /* Energy Detection Threshold */
+
+/* MRF24J40 Long Address Registers */
+#define REG_RFCON0 0x200  /* RF Control Registers */
+#define REG_RFCON1 0x201
+#define REG_RFCON2 0x202
+#define REG_RFCON3 0x203
+#define REG_RFCON5 0x205
+#define REG_RFCON6 0x206
+#define REG_RFCON7 0x207
+#define REG_RFCON8 0x208
+#define REG_RSSI   0x210
+#define REG_SLPCON00x211  /* Sleep Clock Control Registers */
+#define REG_SLPCON10x220
+#define REG_WAKETIMEL  0x222  /* Wake-up Time Match Value Low */
+#define REG_WAKETIMEH  0x223  /* Wake-up Time Match Value High */
+#define REG_RX_FIFO0x300  /* Receive FIFO */
+
+/* Device configuration: Only channels 11-26 on page 0 are supported. */
+#define MRF24J40_CHAN_MIN 11
+#define MRF24J40_CHAN_MAX 26
+#define CHANNEL_MASK (((u32)1 << (MRF24J40_CHAN_MAX + 1)) \
+ - ((u32)1 << MRF24J40_CHAN_MIN))
+
+#define TX_FIFO_SIZE 128 /* From datasheet */
+#define RX_FIFO_SIZE 144 /* From datasheet */
+#define SET_CHANNEL_DELAY_US 192 /* From datasheet */
+
+/* Device Private Data */
+struct mrf24j40 {
+   struct spi_device *spi;
+   struct ieee802154_dev *dev;
+
+   struct mutex buffer_mutex; /* only used to protect buf */
+   struct completion tx_complete;
+   

[PATCH v6 0/1] Driver for Microchip MRF24J40

[Alan Ott]

This is a driver for the Microchip MRF24J40 802.15.4 transceiver.

Versions 1-5 and discussion can be found on the archives of the linux-zigbee
mailing list:

http://www.mail-archive.com/linux-zigbee-devel@lists.sourceforge.net/msg01014.html

Alan Ott (1):
  ieee802154: MRF24J40 driver

 drivers/ieee802154/Kconfig|   11 +
 drivers/ieee802154/Makefile   |1 +
 drivers/ieee802154/mrf24j40.c |  767 +
 3 files changed, 779 insertions(+), 0 deletions(-)
 create mode 100644 drivers/ieee802154/mrf24j40.c

--
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: Using uio_pdrv to create an platform device for an FPGA, mmap() fails

[Hans J. Koch]

[Added driver author to Cc:]

On Wed, Aug 29, 2012 at 11:19:00PM +, Worth, Kevin wrote:
> I have below what appears to be a mostly-functional device using the UIO 
> Platform Driver. The /sys entries I'd expect appear,  /proc/iomem contains " 
> d000-dfff : myfpga", and lsuio sees the properties that I've set. 
> However an mmap() from userspace (either my test program below or lsuio) 
> fails. So close! (at least it would seem)
> 
> Finding a good example for this did not come easily (which is why I'm hitting 
> LKML, since I know it'll get a lot of eyeballs and be archived). Maybe there 
> was something obvious I missed, but the only "official" documentation I could 
> locate was http://www.kernel.org/doc/htmldocs/uio-howto.html#using_uio_pdrv , 
> and most everything else was snippets from presentations, papers, and forums 
> that lacked completeness.
> 
> Thanks for the help any might be able to offer.
> Please CC me on replies as I'm not ready to drink from the fire hose that is 
> an LKML subscription.
> 
> # lsuio -v -m
> uio0: name=uio_myfpga, version=0.1, events=0
> map[0]: addr=0xD000, size=4096, mmap test: FAILED
> Device attributes:
> uevent=DRIVER=uio_pdrv
> modalias=platform:uio_pdrv
> 
> --Kernelspace portion---
> 
> #include 
> #include 
> #include 
> 
> #define MYFPGA_BASE 0xd000 // 3G
> #define MYFPGA_SIZE 0x0004 // 256k
> 
> static struct resource myfpga_resources[] = {
> {
> .start  = MYFPGA_BASE,
> .end= MYFPGA_BASE + MYFPGA_SIZE - 1,
> .name   = "myfpga",
> .flags  = IORESOURCE_MEM
> }
> };
> 
> static struct uio_info myfpga_uio_info = {
>.name = "uio_myfpga",
>.version = "0.1",
>.irq = UIO_IRQ_CUSTOM,
>.mem = {
> {
> .name = "myfpga",
> .memtype = UIO_MEM_PHYS,
> .addr = MYFPGA_BASE,
> .size = MYFPGA_SIZE
> }
> }
> };
> 
> static struct platform_device_info myfpga_uio_pdevinfo = {
> .name = "uio_pdrv",
> .id = -1,
> .res = myfpga_resources,
> .num_res = 1,
> .data = _uio_info,
> .size_data = sizeof(struct uio_info)
> };
> 
> static struct platform_device *myfpga_uio_pdev;
> 
> static int __init myfpga_init(void)
> {
> myfpga_uio_pdev = platform_device_register_full(_uio_pdevinfo);
> if (IS_ERR(myfpga_uio_pdev)) {
> return PTR_ERR(myfpga_uio_pdev);
> }
> 
> return 0;
> }
> 
> static void __exit myfpga_exit(void)
> {
> platform_device_unregister(myfpga_uio_pdev);
> }
> 
> module_init(myfpga_init);
> module_exit(myfpga_exit);
> 
> --Userspace portion---
> 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define MYFPGA_BASE 0xd000 // 3G
> #define MYFPGA_SIZE 0x0004 // 256k
> #define MYFPGA_UIO_NUM  0  // uio0

That's misleading regarding its use below. The factor you need for mmap
is the number of the mapping, not uio0, uio1...

> 
> int main (int argc, char *argv[])
> {
> int fd;
> void *iomem;
> fd = open("/dev/uio0", O_RDWR|O_SYNC);

Does it work with O_RDWR ?

Thanks,
Hans

> if (fd < 0) {
> printf("failed to open /dev/uio0, quitting\n");
> return -1;
> }
> /* Note offset has a special meaning with uio devices */
> iomem = mmap(NULL, MYFPGA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
>  MYFPGA_UIO_NUM * getpagesize());
> if (iomem == MAP_FAILED) {
> printf("mmap failed, quitting\n");
> close(fd);
> return -2;
> }
> printf("mmap successful!\n");
> munmap(iomem, MYFPGA_SIZE);
> close(fd);
> 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/
> 
--
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/2] 6lowpan: handle NETDEV_UNREGISTER event

[Alan Ott]

Before, it was impossible to remove a wpan device which had lowpan
attached to it.

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c |   44 +---
 1 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ce33b02..fb41e08 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1063,12 +1063,6 @@ out:
return (err < 0 ? NETDEV_TX_BUSY : NETDEV_TX_OK);
 }
 
-static void lowpan_dev_free(struct net_device *dev)
-{
-   dev_put(lowpan_dev_info(dev)->real_dev);
-   free_netdev(dev);
-}
-
 static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
 {
struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
@@ -1118,7 +1112,7 @@ static void lowpan_setup(struct net_device *dev)
dev->netdev_ops = _netdev_ops;
dev->header_ops = _header_ops;
dev->ml_priv= _mlme;
-   dev->destructor = lowpan_dev_free;
+   dev->destructor = free_netdev;
 }
 
 static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1244,6 +1238,34 @@ static inline void __init lowpan_netlink_fini(void)
rtnl_link_unregister(_link_ops);
 }
 
+static int lowpan_device_event(struct notifier_block *unused,
+   unsigned long event,
+   void *ptr)
+{
+   struct net_device *dev = ptr;
+   LIST_HEAD(del_list);
+   struct lowpan_dev_record *entry, *tmp;
+
+   if (dev->type != ARPHRD_IEEE802154)
+   goto out;
+
+   if (event == NETDEV_UNREGISTER) {
+   list_for_each_entry_safe(entry, tmp, _devices, list) {
+   if (lowpan_dev_info(entry->ldev)->real_dev == dev)
+   lowpan_dellink(entry->ldev, _list);
+   }
+
+   unregister_netdevice_many(_list);
+   };
+
+out:
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block lowpan_dev_notifier = {
+   .notifier_call = lowpan_device_event,
+};
+
 static struct packet_type lowpan_packet_type = {
.type = __constant_htons(ETH_P_IEEE802154),
.func = lowpan_rcv,
@@ -1258,6 +1280,12 @@ static int __init lowpan_init_module(void)
goto out;
 
dev_add_pack(_packet_type);
+
+   err = register_netdevice_notifier(_dev_notifier);
+   if (err < 0) {
+   dev_remove_pack(_packet_type);
+   lowpan_netlink_fini();
+   }
 out:
return err;
 }
@@ -1270,6 +1298,8 @@ static void __exit lowpan_cleanup_module(void)
 
dev_remove_pack(_packet_type);
 
+   unregister_netdevice_notifier(_dev_notifier);
+
/* Now 6lowpan packet_type is removed, so no new fragments are
 * expected on RX, therefore that's the time to clean incomplete
 * fragments.
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] 6lowpan: Make a copy of skb's delivered to 6lowpan

[Alan Ott]

Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
need our own copy so that it doesn't affect the data received by other
protcols (in this case, af_ieee802154).

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6a09522..ce33b02 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1133,6 +1133,8 @@ static int lowpan_validate(struct nlattr *tb[], struct 
nlattr *data[])
 static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt, struct net_device *orig_dev)
 {
+   struct sk_buff *local_skb;
+
if (!netif_running(dev))
goto drop;
 
@@ -1144,7 +1146,12 @@ static int lowpan_rcv(struct sk_buff *skb, struct 
net_device *dev,
case LOWPAN_DISPATCH_IPHC:  /* ipv6 datagram */
case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
-   lowpan_process_data(skb);
+   local_skb = skb_copy(skb, GFP_ATOMIC);
+   if (!local_skb)
+   goto drop;
+   lowpan_process_data(local_skb);
+
+   kfree_skb(skb);
break;
default:
break;
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] 6lowpan fixes

[Alan Ott]

Fixes for 6lowpan.

I'm sorry about the other two emails that just went out with the same
subject.  One day I'm going to start getting these right on the first try.

Alan Ott (2):
  6lowpan: Make a copy of skb's delivered to 6lowpan
  6lowpan: handle NETDEV_UNREGISTER event

 net/ieee802154/6lowpan.c |   53 +++---
 1 files changed, 45 insertions(+), 8 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/9 V3] workqueue: add POOL_MANAGING_WORKERS

[Lai Jiangshan]

On 08/30/2012 02:21 AM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Thu, Aug 30, 2012 at 12:51:54AM +0800, Lai Jiangshan wrote:
>> When hotplug happens, the plug code will also grab the manager_mutex,
>> it will break too_many_workers()'s assumption, and make too_many_workers()
>> ugly(kick the timer wrongly, no found bug).
>>
>> To avoid assumption-coruption, we add the original POOL_MANAGING_WORKERS 
>> back.
> 
> I don't think we're gaining anything with this and I'd like to confine
> management state within the mutex only.  If too_many_workers() firing
> spuriously while CPU up/down is in progress, just add a comment
> explaining why it's a non-problem

OK, I drop this patch, Could you add the comment, I'm not good at English.

> (actual worker management never
> happens while cpu up/down holds manager positions).
> 

I don't agree this claim. It happens "rarely", not "never", otherwise I missed 
something.


Thanks,
Lai
--
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] 6lowpan: handle NETDEV_UNREGISTER event

[Alan Ott]

Before, it was impossible to remove a wpan device which had lowpan
attached to it.

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c |   44 +---
 1 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ce33b02..fb41e08 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1063,12 +1063,6 @@ out:
return (err < 0 ? NETDEV_TX_BUSY : NETDEV_TX_OK);
 }
 
-static void lowpan_dev_free(struct net_device *dev)
-{
-   dev_put(lowpan_dev_info(dev)->real_dev);
-   free_netdev(dev);
-}
-
 static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
 {
struct net_device *real_dev = lowpan_dev_info(dev)->real_dev;
@@ -1118,7 +1112,7 @@ static void lowpan_setup(struct net_device *dev)
dev->netdev_ops = _netdev_ops;
dev->header_ops = _header_ops;
dev->ml_priv= _mlme;
-   dev->destructor = lowpan_dev_free;
+   dev->destructor = free_netdev;
 }
 
 static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1244,6 +1238,34 @@ static inline void __init lowpan_netlink_fini(void)
rtnl_link_unregister(_link_ops);
 }
 
+static int lowpan_device_event(struct notifier_block *unused,
+   unsigned long event,
+   void *ptr)
+{
+   struct net_device *dev = ptr;
+   LIST_HEAD(del_list);
+   struct lowpan_dev_record *entry, *tmp;
+
+   if (dev->type != ARPHRD_IEEE802154)
+   goto out;
+
+   if (event == NETDEV_UNREGISTER) {
+   list_for_each_entry_safe(entry, tmp, _devices, list) {
+   if (lowpan_dev_info(entry->ldev)->real_dev == dev)
+   lowpan_dellink(entry->ldev, _list);
+   }
+
+   unregister_netdevice_many(_list);
+   };
+
+out:
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block lowpan_dev_notifier = {
+   .notifier_call = lowpan_device_event,
+};
+
 static struct packet_type lowpan_packet_type = {
.type = __constant_htons(ETH_P_IEEE802154),
.func = lowpan_rcv,
@@ -1258,6 +1280,12 @@ static int __init lowpan_init_module(void)
goto out;
 
dev_add_pack(_packet_type);
+
+   err = register_netdevice_notifier(_dev_notifier);
+   if (err < 0) {
+   dev_remove_pack(_packet_type);
+   lowpan_netlink_fini();
+   }
 out:
return err;
 }
@@ -1270,6 +1298,8 @@ static void __exit lowpan_cleanup_module(void)
 
dev_remove_pack(_packet_type);
 
+   unregister_netdevice_notifier(_dev_notifier);
+
/* Now 6lowpan packet_type is removed, so no new fragments are
 * expected on RX, therefore that's the time to clean incomplete
 * fragments.
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 6lowpan: Make a copy of skb's delivered to 6lowpan

[Alan Ott]

Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
need our own copy so that it doesn't affect the data received by other
protcols (in this case, af_ieee802154).

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 6a09522..ce33b02 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1133,6 +1133,8 @@ static int lowpan_validate(struct nlattr *tb[], struct 
nlattr *data[])
 static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt, struct net_device *orig_dev)
 {
+   struct sk_buff *local_skb;
+
if (!netif_running(dev))
goto drop;
 
@@ -1144,7 +1146,12 @@ static int lowpan_rcv(struct sk_buff *skb, struct 
net_device *dev,
case LOWPAN_DISPATCH_IPHC:  /* ipv6 datagram */
case LOWPAN_DISPATCH_FRAG1: /* first fragment header */
case LOWPAN_DISPATCH_FRAGN: /* next fragments headers */
-   lowpan_process_data(skb);
+   local_skb = skb_copy(skb, GFP_ATOMIC);
+   if (!local_skb)
+   goto drop;
+   lowpan_process_data(local_skb);
+
+   kfree_skb(skb);
break;
default:
break;
-- 
1.7.0.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 0/2] Renesas IPMMU driver for sh7372

[Damian Hobson-Garcia]

Hi Simon,

On 2012/08/25 16:13, Simon Horman wrote:
> On Wed, Jul 25, 2012 at 03:29:00PM +0900, Hideki EIRAKU wrote:
>> This is the Renesas IPMMU driver, IOMMU API implementation and IPMMU
>> device support for sh7372 (AP4EVB and Mackerel).
>>
>> The IPMMU module supports the MMU function and the PMB function.  The
>> MMU function provides address translation by pagetable compatible with
>> ARMv6.  The PMB function provides address translation including
>> tile-linear translation.  This is implementation of the MMU function.
> 
> Hi,
> 
> I am wondering if anyone has had a chance to review this short series.
> It seems reasonable to me with the minor exception that I would
> be happier the second patch to update the relevant defconfigs
> to either enable or disable the driver.
> 
> I am also curious to know how this driver may be tested.

Since this patch series configures the LCDC, and CEU to use the IPMMU,
checking the memory addresses that those blocks are using are properly
registered in the IPMMU, and verifying that they actually function seems
like the best way to test this driver. I'll take a look at doing that.

That said, there currently isn't any way to use this with UIO devices,
since enabling the IPMMU with break direct accesses to physical memory
from all of the IP blocks on the ICB (LCDC, CEU, VPU, VEU, etc.)
For these devices, memory allocated with the dma-mapping API *must* be
used with IPMMU enabled.  The current uio_pdrv_genirq driver isn't set
up to deal with this right now.

Damian
--
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 v10] kvm: notify host when the guest is panicked

[Wen Congyang]

At 08/29/2012 07:56 PM, Sasha Levin Wrote:
> On 08/29/2012 07:18 AM, Wen Congyang wrote:
>> We can know the guest is panicked when the guest runs on xen.
>> But we do not have such feature on kvm.
>>
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump when the guest is panicked. If management
>> app does not do auto dump, the guest's user can do dump by hand if
>> he sees the guest is panicked.
>>
>> We have three solutions to implement this feature:
>> 1. use vmcall
>> 2. use I/O port
>> 3. use virtio-serial.
>>
>> We have decided to avoid touching hypervisor. The reason why I choose
>> choose the I/O port is:
>> 1. it is easier to implememt
>> 2. it does not depend any virtual device
>> 3. it can work when starting the kernel
>>
>> Signed-off-by: Wen Congyang 
>> ---
>>  Documentation/virtual/kvm/pv_event.txt |   32 
>> 
>>  arch/ia64/include/asm/kvm_para.h   |   14 ++
>>  arch/powerpc/include/asm/kvm_para.h|   14 ++
>>  arch/s390/include/asm/kvm_para.h   |   14 ++
>>  arch/x86/include/asm/kvm_para.h|   27 +++
>>  arch/x86/kernel/kvm.c  |   25 +
>>  include/linux/kvm_para.h   |   23 +++
>>  7 files changed, 149 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/virtual/kvm/pv_event.txt
>>
>> diff --git a/Documentation/virtual/kvm/pv_event.txt 
>> b/Documentation/virtual/kvm/pv_event.txt
>> new file mode 100644
>> index 000..bb04de0
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/pv_event.txt
>> @@ -0,0 +1,32 @@
>> +The KVM paravirtual event interface
>> +=
>> +
>> +Initializing the paravirtual event interface
>> +==
>> +kvm_pv_event_init()
>> +Argiments:
>> +None
>> +
>> +Return Value:
>> +0: The guest kernel can use paravirtual event interface.
>> +1: The guest kernel can't use paravirtual event interface.
>> +
>> +Querying whether the event can be ejected
>> +==
>> +kvm_pv_has_feature()
>> +Arguments:
>> +feature: The bit value of this paravirtual event to query
>> +
>> +Return Value:
>> +0 : The guest kernel can't eject this paravirtual event.
>> +-1: The guest kernel can eject this paravirtual event.
>> +
>> +
>> +Ejecting paravirtual event
>> +==
>> +kvm_pv_eject_event()
>> +Arguments:
>> +event: The event to be ejected.
>> +
>> +Return Value:
>> +None
> 
> What's the protocol for communicating with the hypervisor? What is it supposed
> to do on reads/writes to that ioport?

Not only ioport, the other arch can use some other ways. We can use
these APIs to eject event to hypervisor. The caller does not care how
to communicate with the hypervisor.

> 
>> diff --git a/arch/x86/include/asm/kvm_para.h 
>> b/arch/x86/include/asm/kvm_para.h
>> index 2f7712e..7d297f0 100644
>> --- a/arch/x86/include/asm/kvm_para.h
>> +++ b/arch/x86/include/asm/kvm_para.h
>> @@ -96,8 +96,11 @@ struct kvm_vcpu_pv_apf_data {
>>  #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
>>  #define KVM_PV_EOI_DISABLED 0x0
>>  
>> +#define KVM_PV_EVENT_PORT   (0x505UL)
>> +
>>  #ifdef __KERNEL__
>>  #include 
>> +#include 
>>  
>>  extern void kvmclock_init(void);
>>  extern int kvm_register_clock(char *txt);
>> @@ -228,6 +231,30 @@ static inline void kvm_disable_steal_time(void)
>>  }
>>  #endif
>>  
>> +static inline int kvm_arch_pv_event_init(void)
>> +{
>> +if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
> 
> Only one byte is requested here, but the rest of the code is reading/writing 
> longs?
> 
> The struct resource * returned from request_region is simply being leaked 
> here?
> 
> What happens if we go ahead with adding another event (let's say OOM event)?
> request_region() is going to fail for anything but the first call.

For x86, we use ioport to communicate with hypervisor. We can read a 32bit value
from the hypervisor. If the bit0 is setted, it means the hypervisor supports
panicked event. If you want add another event, you can use another unused bit.
I think 32 events are enough now.

You can write a value to the ioport to eject the event. Only one event can be
ejected at a time.

> 
>> +return -1;
> 
> This return value doesn't correspond with the documentation.

Yes, I will update the document. Thanks for pointing it out.

> 
>> +
>> +return 0;
>> +}
>> +
>> +static inline unsigned int kvm_arch_pv_features(void)
>> +{
>> +unsigned int features = inl(KVM_PV_EVENT_PORT);
>> +
>> +/* Reading from an invalid I/O port will return -1 */
> 
> Just wondering, where is that documented? For lkvm for example the return 
> value
> from an ioport without a device on the other side is undefined, so it's 
> possible
> we're doing something wrong there.

Hmm, how to use lkvm? Can you give me a example. So I can test this patch on 

Re: [PATCH v6] mmc: card: Skip secure option for MoviNAND.

[Chris Ball]

Hi,

On Wed, Aug 29 2012, IAN CHEN wrote:
> Thanks for your help.
> The effected kernel will be all the version with MMC_CAP_ERASE & SECURE
> option enabled.
> As commit content mentioned, the problem is unrecoverable corruption after
> SECURE ERASE or SECURE TRIM.
> For devices using defective eMMC with kernel supporting MMC_CAP_ERASE &
> SECURE option, this issue might cause damage.
> Therefore, we skip secure for these known devices.

Thanks, pushed to mmc-next for 3.6 with a stable@ tag.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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 v6] mmc: card: Skip secure option for MoviNAND.

[IAN CHEN]

Hi,

Thanks for your help.
The effected kernel will be all the version with MMC_CAP_ERASE & SECURE
option enabled.
As commit content mentioned, the problem is unrecoverable corruption after
SECURE ERASE or SECURE TRIM.
For devices using defective eMMC with kernel supporting MMC_CAP_ERASE &
SECURE option, this issue might cause damage.
Therefore, we skip secure for these known devices.

Regards,
Ian

-Original Message-
From: Chris Ball [mailto:c...@laptop.org] 
Sent: Wednesday, August 29, 2012 7:27 PM

Hi,

On Wed, Aug 29 2012, IAN CHEN wrote:
> For several MoviNAND, there are some known issue with secure option.
> For these specific MoviNAND device, we skip secure option.
>
> You could refer this discussion in XDA developers.
> http://forum.xda-developers.com/showthread.php?t=1644364
>
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184
813224730/posts/21pTYfTsCkB
>
> Signed-off-by: Ian Chen 
> Reviewed-by: Namjae Jeon 
> Acked-by: Jaehoon Chung 
> Reviewed-by: Linus Walleij 

Thanks.  We should explain the nature of the bug in the commit message,
so that users and the stable@ maintainers know how bad the problem is
by reading the patch.  (This should go to stable@, right?  Do you know
which kernel versions are affected?)

I'll add something like this, unless you have a better proposal:

==
For several MoviNAND, there are some known issues with secure option.
For these specific MoviNAND device, we skip secure option.

Specifically, there is a bug in the eMMC firmware that causes 
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

You could refer this discussion in XDA developers.
http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184
813224730/posts/21pTYfTsCkB
==

- Chris.
-- 
Chris Ball  
One Laptop Per Child

--
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 6/7] net/netfilter/nfnetlink_log.c: fix error return code

[Pablo Neira Ayuso]

On Wed, Aug 29, 2012 at 06:49:17PM +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Initialize return variable before exiting on an error path.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> 
> // 

And also applied, thanks Julia. I'll pass these to current -rc.
--
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 7/7] net/netfilter/nf_conntrack_netlink.c: fix error return code

[Pablo Neira Ayuso]

On Wed, Aug 29, 2012 at 06:49:16PM +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Initialize return variable before exiting on an error path.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> 
> // 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] ipvs: fix error return code

[Pablo Neira Ayuso]

On Wed, Aug 29, 2012 at 06:49:11PM +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Initialize return variable before exiting on an error path.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> 
> // 

Applied. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] create sun sysfs file

[Yasuaki Ishimatsu]

Hi Len,

Three weeks passed after I post the patch.
All comments have already been applied to it. And I think there is no
comments about it. So I want you to merge it into your tree.

Thanks,
Yasuaki Ishimatsu

2012/08/07 9:36, Yasuaki Ishimatsu wrote:
> Even if a device has _SUN method, there is no way to know the slot unique-ID.
> Thus the patch creates "sun" file in sysfs so that we can recognize it.
> 
> Reviewed-by: Toshi Kani 
> Signed-off-by: Yasuaki Ishimatsu 
> 
> ---
>   drivers/acpi/scan.c |   24 
>   include/acpi/acpi_bus.h |1 +
>   2 files changed, 25 insertions(+)
> 
> Index: linux-3.5/include/acpi/acpi_bus.h
> ===
> --- linux-3.5.orig/include/acpi/acpi_bus.h2012-07-30 10:06:49.722171575 
> +0900
> +++ linux-3.5/include/acpi/acpi_bus.h 2012-08-07 08:57:45.678204360 +0900
> @@ -209,6 +209,7 @@ struct acpi_device_pnp {
>   struct list_head ids;   /* _HID and _CIDs */
>   acpi_device_name device_name;   /* Driver-determined */
>   acpi_device_class device_class; /*"  */
> + unsigned long sun;  /* _SUN */
>   };
>   
>   #define acpi_device_bid(d)  ((d)->pnp.bus_id)
> Index: linux-3.5/drivers/acpi/scan.c
> ===
> --- linux-3.5.orig/drivers/acpi/scan.c2012-07-30 10:06:49.713171688 
> +0900
> +++ linux-3.5/drivers/acpi/scan.c 2012-08-07 09:01:38.196203659 +0900
> @@ -192,10 +192,20 @@ end:
>   }
>   static DEVICE_ATTR(path, 0444, acpi_device_path_show, NULL);
>   
> +static ssize_t
> +acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
> +  char *buf) {
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> +
> + return sprintf(buf, "%lu\n", acpi_dev->pnp.sun);
> +}
> +static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
> +
>   static int acpi_device_setup_files(struct acpi_device *dev)
>   {
>   acpi_status status;
>   acpi_handle temp;
> + unsigned long long sun;
>   int result = 0;
>   
>   /*
> @@ -217,6 +227,16 @@ static int acpi_device_setup_files(struc
>   goto end;
>   }
>   
> + status = acpi_evaluate_integer(dev->handle, "_SUN", NULL, );
> + if (ACPI_SUCCESS(status)) {
> + dev->pnp.sun = (unsigned long)sun;
> + result = device_create_file(>dev, _attr_sun);
> + if (result)
> + goto end;
> + } else {
> + dev->pnp.sun = (unsigned long)-1;
> + }
> +
>   /*
>* If device has _EJ0, 'eject' file is created that is used to 
> trigger
>* hot-removal function from userland.
> @@ -241,6 +261,10 @@ static void acpi_device_remove_files(str
>   if (ACPI_SUCCESS(status))
>   device_remove_file(>dev, _attr_eject);
>   
> + status = acpi_get_handle(dev->handle, "_SUN", );
> + if (ACPI_SUCCESS(status))
> + device_remove_file(>dev, _attr_sun);
> +
>   device_remove_file(>dev, _attr_modalias);
>   device_remove_file(>dev, _attr_hid);
>   if (dev->handle)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
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: Drop support for x86-32

[david]

On Fri, 24 Aug 2012, Theodore Ts'o wrote:


On Fri, Aug 24, 2012 at 11:17:20AM -0700, H. Peter Anvin wrote:


Speaking as one of the x86 maintainers... we are currently deciding the
cost/benefit tradeoff around removing i386 support.  I don't mean
general x86-32 support, I mean i386 as opposed to i486, Pentium, and so on.


Random question.  As I recall the Space Shuttle and the International
Space Station was only using 80386's because they have to be hardened
against radiation/cosmic rays, as well as all of the other mechnical
and thermal stresses associated with being in a spacecraft.  Is there
any newer generation cpu's which are space-cerified at this point?

(Of course, I'm rather doubtful that NASA would ever be willing to use
Linux on something like the Curiosity Mars Rover, but I could imagine
Linux being used in a non-mission critcal system on the ISS)


I've heard that there are radiation hardened versions of the 80486 (I 
could be wrong, it's not something that I've ever needed to investigate)


David Lang
--
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/7] ipvs: fix error return code

[Simon Horman]

On Wed, Aug 29, 2012 at 06:49:11PM +0200, Julia Lawall wrote:
> From: Julia Lawall 
> 
> Initialize return variable before exiting on an error path.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> 
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  net/netfilter/ipvs/ip_vs_ctl.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 3c60137..767cc12 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -1171,8 +1171,10 @@ ip_vs_add_service(struct net *net, struct 
> ip_vs_service_user_kern *u,
>   goto out_err;
>   }
>   svc->stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
> - if (!svc->stats.cpustats)
> + if (!svc->stats.cpustats) {
> + ret = -ENOMEM;
>   goto out_err;
> + }
>  
>   /* I'm the first user of the service */
>   atomic_set(>usecnt, 0);

Acked-by: Simon Horman 
--
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/

CMA page migration failure due to buffers on bh_lru

[Laura Abbott]

Hi,

I've been observing a high rate of failures with CMA allocations on my
ARM system. I've set up a test case set up with a 56MB CMA region that
essentially does the following:

total_failures = 0;
loop forever:
loop_failure = 0;
for (i = 0; i < 56; i++)
chunk[i] = dma_allocate(_dev, 1MB)
if (!chunk[i])
loop_failure = 0

if (loop_failure)
total_failures++
loop_failure = 0

for (i = 0; i < 56; i++)
dma_free(_dev, chunk[i], 1MB)

In the background, I also have a process doing some amount of filesystem
activity (adb push/pull since this is an android system). During the 
course of my investigations I generally get ~8500 loops total and ~450 
total failures (i.e. one or more buffers could not be allocated). This 
is unacceptably high for our use cases.


In every case the allocation failure was ultimately due to a migration
failure; the pages contained buffers which could not be dropped because 
the buffers were busy (move_to_new_page -> fallback_migrate_page ->
try_to_release_page -> try_to_free_buffers -> drop_buffers -> 
buffer_busy). In every case, the b_count on the buffer head was always 1.


The problem arises because of the LRU lists for buffer heads:

__getblk
__getblk_slow
grow_buffers
grow_dev_page
find_or_create_page -- create a possibly movable page
__find_get_block
__find_get_block_slow
find_get_page -- return the movable page
bh_lru_install
get_bh -- buffer head now has a reference

The reference taken in bh_lru_install won't be dropped until the bh is 
evicted from the lru. This means the page cannot be migrated as long as 
the buffer exists on an LRU list. The real issue is that unless the 
buffer gets evicted quickly the page can remain non-migratible for long 
periods of time. This makes CMA regions unusable for long periods of 
time given that we generally don't want to size CMA regions any larger 
than necessary ergo any failure will cause a problem.


My quick and dirty workaround for testing is to remove the GFP_MOVABLE 
flag from find_or_create_page but this seems significantly less than 
optimal. Ideally, it seems like the buffers should be evicted from the 
LRU when trying to drop (expand on invalid_bh_lru?) but I'm not familiar 
enough with the code path to know if this is a good approach.


Any suggestions/feedback is appreciated. Thanks.

Laura
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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] rpmsg: use right device paramter when calling dma_free_coherent function

[Fernando Guzman Lugo]

dma_alloc/free_coherent APIs requires the platform specific remoteproc
device as the device parameter. We are passing vdev->dev.parent to the
dma_free_coherent function which is the generic rproc device and it is
wrong, it has to be vdev->dev.parent->parent instead, same as when we
call dma_alloc_coherent function.

Signed-off-by: Fernando Guzman Lugo 
---
 drivers/rpmsg/virtio_rpmsg_bus.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 590cfaf..1859f71 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -1008,8 +1008,8 @@ static int rpmsg_probe(struct virtio_device *vdev)
return 0;
 
 free_coherent:
-   dma_free_coherent(vdev->dev.parent, RPMSG_TOTAL_BUF_SPACE, bufs_va,
-   vrp->bufs_dma);
+   dma_free_coherent(vdev->dev.parent->parent, RPMSG_TOTAL_BUF_SPACE,
+   bufs_va, vrp->bufs_dma);
 vqs_del:
vdev->config->del_vqs(vrp->vdev);
 free_vrp:
@@ -1043,7 +1043,7 @@ static void __devexit rpmsg_remove(struct virtio_device 
*vdev)
 
vdev->config->del_vqs(vrp->vdev);
 
-   dma_free_coherent(vdev->dev.parent, RPMSG_TOTAL_BUF_SPACE,
+   dma_free_coherent(vdev->dev.parent->parent, RPMSG_TOTAL_BUF_SPACE,
vrp->rbufs, vrp->bufs_dma);
 
kfree(vrp);
-- 
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/

Re: WARNING: at fs/inode.c:280 drop_nlink+0x31/0x33()

[Nick Pasich]

Thanks for replying Jeff...

Yes, it sure would be great to have 3.5.z  patch...


--( Nick Pasich )--



On Wed, Aug 29, 2012 at 03:16:41PM -0700, Jeff Layton wrote:
> On Wed, 29 Aug 2012 09:25:27 -0700
> Nick Pasich  wrote:
> 
> > 
> > I'm using kernel 3.5.3 ... 
> > 
> > It happens on 3.5.1 and 3.5.2 also.
> > 
> > I know that Nick Bowler has already reported this...
> > 
> > I'm experiencing the same thing.
> > 
> > It happens when moving files from one directory to another
> > on the same partition (NFS). 
> > 
> >   --( Nick Pasich )--
> > 
> > 
> > #
> > ##
> > ## Happens when PSTs are moved from one directory to another on the ISCSI 
> > ...
> > ##
> > #
> > 
> > Aug 29 08:06:16 localhost kernel: [ cut here ]
> > Aug 29 08:06:16 localhost kernel: WARNING: at fs/inode.c:280 
> > drop_nlink+0x31/0x33()
> > Aug 29 08:06:16 localhost kernel: Hardware name: To Be Filled By O.E.M.
> > Aug 29 08:06:16 localhost kernel: Modules linked in: ecb md4 cifs w83627hf 
> > eeprom asb100 hwmon_vid hwmon nfsd exportfs ipv6 psmouse usb_storage 
> > io_edgeport usbserial sg r8169 mii evdev intel_agp uhci_hcd i2c_i801 
> > i2c_core shpchp intel_gtt agpgart ehci_hcd microcode serio_raw
> > Aug 29 08:06:16 localhost kernel: Pid: 31477, comm: rm Tainted: GW  
> >   3.5.3 #1
> > Aug 29 08:06:16 localhost kernel: Call Trace:
> > Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> > Aug 29 08:06:16 localhost kernel:  [] ? 
> > warn_slowpath_common+0x7b/0x90
> > Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> > Aug 29 08:06:16 localhost kernel:  [] ? 
> > warn_slowpath_null+0x1b/0x1f
> > Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> > Aug 29 08:06:16 localhost kernel:  [] ? cifs_unlink+0x134/0x63d 
> > [cifs]
> > Aug 29 08:06:16 localhost kernel:  [] ? dput+0x11/0x117
> > Aug 29 08:06:16 localhost kernel:  [] ? mntput_no_expire+0xf/0xf7
> > Aug 29 08:06:16 localhost kernel:  [] ? vfs_unlink+0x4e/0xb6
> > Aug 29 08:06:16 localhost kernel:  [] ? __lookup_hash+0x54/0xac
> > Aug 29 08:06:16 localhost kernel:  [] ? do_unlinkat+0x10a/0x12d
> > Aug 29 08:06:16 localhost kernel:  [] ? sys_ioctl+0x34/0x57
> > Aug 29 08:06:16 localhost kernel:  [] ? syscall_call+0x7/0xb
> > Aug 29 08:06:16 localhost kernel: ---[ end trace 756b427e3bd671f9 ]---
> > 
> 
> (cc'ing linux-cifs ml)
> 
> This stack trace comes from cifs, not nfs.
> 
> Steve French has a patch queued in his tree to silence this warning
> that I believe he intends to send to Linus for 3.6. Perhaps we should
> consider backporting it for 3.5.z too?
> 
> -- 
> Jeff Layton 

--
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] ARM: smp: Fix cpu_up() racing with sys_reboot

[Russell King - ARM Linux]

On Tue, Aug 21, 2012 at 09:03:49PM -0700, Stephen Boyd wrote:
> Nothing stops a process from hotplugging in a CPU concurrently
> with a sys_reboot() call. In such a situation we could have
> ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
> fact that the CPU is not really offline and call the
> CPU_UP_PREPARE notifier. When this happens stop_machine code will
> complain that the cpu thread already exists and BUG_ON().

This puts us at odds with x86, which is a bad thing without first
investigating whether a generic solution which fixes all arches would
be more appropriate.

A better solution may be to mark those CPUs as being not-present,
which will prevent them being hot-plugged back.
--
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: Drop support for x86-32

[Jeff Garzik]

On Wed, Aug 29, 2012 at 7:03 PM, Mark Lord  wrote:
> On 12-08-26 10:15 AM, wbrana wrote:
>> On 8/26/12, Mark Lord  wrote:
>>> Here are a couple of real scenarios you don't seem to have thought about.
>>> A 32-bit kernel on a legacy (or even new) system in 2017 will still need
>>> regular kernel updates (not "long term" un0maintained kernels)
>>> in order to work with new USB devices, new 4KB+ sector hard drives,
>>> newer generations of SSDs, etc..
>> 12-years-old machine is trash.
>
> There you go making assumptions again.
> Who said anything about a 12-year old machine?
>
> Much more likely is a 5-year old software installation
> that gets moved to a new box.

Or a brand new software installation into a 32-bit virtual machine.

 Jeff
--
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] KVM: x86: mark opcode tables const

[Mathias Krause]

The opcode tables never change at runtime, therefor mark them const.

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/emulate.c |   40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 5a0fee1..fd06f9d 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -161,9 +161,9 @@ struct opcode {
u64 intercept : 8;
union {
int (*execute)(struct x86_emulate_ctxt *ctxt);
-   struct opcode *group;
-   struct group_dual *gdual;
-   struct gprefix *gprefix;
+   const struct opcode *group;
+   const struct group_dual *gdual;
+   const struct gprefix *gprefix;
} u;
int (*check_perm)(struct x86_emulate_ctxt *ctxt);
 };
@@ -3574,13 +3574,13 @@ static int check_perm_out(struct x86_emulate_ctxt *ctxt)
I2bv(((_f) | DstReg | SrcMem | ModRM) & ~Lock, _e), \
I2bv(((_f) & ~Lock) | DstAcc | SrcImm, _e)
 
-static struct opcode group7_rm1[] = {
+static const struct opcode group7_rm1[] = {
DI(SrcNone | Priv, monitor),
DI(SrcNone | Priv, mwait),
N, N, N, N, N, N,
 };
 
-static struct opcode group7_rm3[] = {
+static const struct opcode group7_rm3[] = {
DIP(SrcNone | Prot | Priv,  vmrun,  check_svme_pa),
II(SrcNone  | Prot | VendorSpecific,em_vmmcall, vmmcall),
DIP(SrcNone | Prot | Priv,  vmload, check_svme_pa),
@@ -3591,13 +3591,13 @@ static struct opcode group7_rm3[] = {
DIP(SrcNone | Prot | Priv,  invlpga,check_svme),
 };
 
-static struct opcode group7_rm7[] = {
+static const struct opcode group7_rm7[] = {
N,
DIP(SrcNone, rdtscp, check_rdtsc),
N, N, N, N, N, N,
 };
 
-static struct opcode group1[] = {
+static const struct opcode group1[] = {
I(Lock, em_add),
I(Lock | PageTable, em_or),
I(Lock, em_adc),
@@ -3608,11 +3608,11 @@ static struct opcode group1[] = {
I(0, em_cmp),
 };
 
-static struct opcode group1A[] = {
+static const struct opcode group1A[] = {
I(DstMem | SrcNone | Mov | Stack, em_pop), N, N, N, N, N, N, N,
 };
 
-static struct opcode group3[] = {
+static const struct opcode group3[] = {
I(DstMem | SrcImm, em_test),
I(DstMem | SrcImm, em_test),
I(DstMem | SrcNone | Lock, em_not),
@@ -3623,13 +3623,13 @@ static struct opcode group3[] = {
I(SrcMem, em_idiv_ex),
 };
 
-static struct opcode group4[] = {
+static const struct opcode group4[] = {
I(ByteOp | DstMem | SrcNone | Lock, em_grp45),
I(ByteOp | DstMem | SrcNone | Lock, em_grp45),
N, N, N, N, N, N,
 };
 
-static struct opcode group5[] = {
+static const struct opcode group5[] = {
I(DstMem | SrcNone | Lock,  em_grp45),
I(DstMem | SrcNone | Lock,  em_grp45),
I(SrcMem | Stack,   em_grp45),
@@ -3639,7 +3639,7 @@ static struct opcode group5[] = {
I(SrcMem | Stack,   em_grp45), N,
 };
 
-static struct opcode group6[] = {
+static const struct opcode group6[] = {
DI(Prot,sldt),
DI(Prot,str),
II(Prot | Priv | SrcMem16, em_lldt, lldt),
@@ -3647,7 +3647,7 @@ static struct opcode group6[] = {
N, N, N, N,
 };
 
-static struct group_dual group7 = { {
+static const struct group_dual group7 = { {
II(Mov | DstMem | Priv, em_sgdt, sgdt),
II(Mov | DstMem | Priv, em_sidt, sidt),
II(SrcMem | Priv,   em_lgdt, lgdt),
@@ -3664,7 +3664,7 @@ static struct group_dual group7 = { {
EXT(0, group7_rm7),
 } };
 
-static struct opcode group8[] = {
+static const struct opcode group8[] = {
N, N, N, N,
I(DstMem | SrcImmByte,  em_bt),
I(DstMem | SrcImmByte | Lock | PageTable,   em_bts),
@@ -3672,26 +3672,26 @@ static struct opcode group8[] = {
I(DstMem | SrcImmByte | Lock | PageTable,   em_btc),
 };
 
-static struct group_dual group9 = { {
+static const struct group_dual group9 = { {
N, I(DstMem64 | Lock | PageTable, em_cmpxchg8b), N, N, N, N, N, N,
 }, {
N, N, N, N, N, N, N, N,
 } };
 
-static struct opcode group11[] = {
+static const struct opcode group11[] = {
I(DstMem | SrcImm | Mov | PageTable, em_mov),
X7(D(Undefined)),
 };
 
-static struct gprefix pfx_0f_6f_0f_7f = {
+static const struct gprefix pfx_0f_6f_0f_7f = {
I(Mmx, em_mov), I(Sse | Aligned, em_mov), N, I(Sse | Unaligned, em_mov),
 };
 
-static struct gprefix pfx_vmovntpx = {
+static const struct gprefix pfx_vmovntpx = {
I(0, em_mov), N, N, N,
 };
 
-static struct opcode opcode_table[256] = {
+static const struct opcode opcode_table[256] = {
/* 0x00 - 0x07 */
I6ALU(Lock, em_add),
   

[PATCH 2/8] KVM: x86 emulator: use aligned variants of SSE register ops

[Mathias Krause]

As the the compiler ensures that the memory operand is always aligned
to a 16 byte memory location, use the aligned variant of MOVDQ for
read_sse_reg() and write_sse_reg().

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/emulate.c |   64 
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 1451cff..5a0fee1 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -909,23 +909,23 @@ static void read_sse_reg(struct x86_emulate_ctxt *ctxt, 
sse128_t *data, int reg)
 {
ctxt->ops->get_fpu(ctxt);
switch (reg) {
-   case 0: asm("movdqu %%xmm0, %0" : "=m"(*data)); break;
-   case 1: asm("movdqu %%xmm1, %0" : "=m"(*data)); break;
-   case 2: asm("movdqu %%xmm2, %0" : "=m"(*data)); break;
-   case 3: asm("movdqu %%xmm3, %0" : "=m"(*data)); break;
-   case 4: asm("movdqu %%xmm4, %0" : "=m"(*data)); break;
-   case 5: asm("movdqu %%xmm5, %0" : "=m"(*data)); break;
-   case 6: asm("movdqu %%xmm6, %0" : "=m"(*data)); break;
-   case 7: asm("movdqu %%xmm7, %0" : "=m"(*data)); break;
+   case 0: asm("movdqa %%xmm0, %0" : "=m"(*data)); break;
+   case 1: asm("movdqa %%xmm1, %0" : "=m"(*data)); break;
+   case 2: asm("movdqa %%xmm2, %0" : "=m"(*data)); break;
+   case 3: asm("movdqa %%xmm3, %0" : "=m"(*data)); break;
+   case 4: asm("movdqa %%xmm4, %0" : "=m"(*data)); break;
+   case 5: asm("movdqa %%xmm5, %0" : "=m"(*data)); break;
+   case 6: asm("movdqa %%xmm6, %0" : "=m"(*data)); break;
+   case 7: asm("movdqa %%xmm7, %0" : "=m"(*data)); break;
 #ifdef CONFIG_X86_64
-   case 8: asm("movdqu %%xmm8, %0" : "=m"(*data)); break;
-   case 9: asm("movdqu %%xmm9, %0" : "=m"(*data)); break;
-   case 10: asm("movdqu %%xmm10, %0" : "=m"(*data)); break;
-   case 11: asm("movdqu %%xmm11, %0" : "=m"(*data)); break;
-   case 12: asm("movdqu %%xmm12, %0" : "=m"(*data)); break;
-   case 13: asm("movdqu %%xmm13, %0" : "=m"(*data)); break;
-   case 14: asm("movdqu %%xmm14, %0" : "=m"(*data)); break;
-   case 15: asm("movdqu %%xmm15, %0" : "=m"(*data)); break;
+   case 8: asm("movdqa %%xmm8, %0" : "=m"(*data)); break;
+   case 9: asm("movdqa %%xmm9, %0" : "=m"(*data)); break;
+   case 10: asm("movdqa %%xmm10, %0" : "=m"(*data)); break;
+   case 11: asm("movdqa %%xmm11, %0" : "=m"(*data)); break;
+   case 12: asm("movdqa %%xmm12, %0" : "=m"(*data)); break;
+   case 13: asm("movdqa %%xmm13, %0" : "=m"(*data)); break;
+   case 14: asm("movdqa %%xmm14, %0" : "=m"(*data)); break;
+   case 15: asm("movdqa %%xmm15, %0" : "=m"(*data)); break;
 #endif
default: BUG();
}
@@ -937,23 +937,23 @@ static void write_sse_reg(struct x86_emulate_ctxt *ctxt, 
sse128_t *data,
 {
ctxt->ops->get_fpu(ctxt);
switch (reg) {
-   case 0: asm("movdqu %0, %%xmm0" : : "m"(*data)); break;
-   case 1: asm("movdqu %0, %%xmm1" : : "m"(*data)); break;
-   case 2: asm("movdqu %0, %%xmm2" : : "m"(*data)); break;
-   case 3: asm("movdqu %0, %%xmm3" : : "m"(*data)); break;
-   case 4: asm("movdqu %0, %%xmm4" : : "m"(*data)); break;
-   case 5: asm("movdqu %0, %%xmm5" : : "m"(*data)); break;
-   case 6: asm("movdqu %0, %%xmm6" : : "m"(*data)); break;
-   case 7: asm("movdqu %0, %%xmm7" : : "m"(*data)); break;
+   case 0: asm("movdqa %0, %%xmm0" : : "m"(*data)); break;
+   case 1: asm("movdqa %0, %%xmm1" : : "m"(*data)); break;
+   case 2: asm("movdqa %0, %%xmm2" : : "m"(*data)); break;
+   case 3: asm("movdqa %0, %%xmm3" : : "m"(*data)); break;
+   case 4: asm("movdqa %0, %%xmm4" : : "m"(*data)); break;
+   case 5: asm("movdqa %0, %%xmm5" : : "m"(*data)); break;
+   case 6: asm("movdqa %0, %%xmm6" : : "m"(*data)); break;
+   case 7: asm("movdqa %0, %%xmm7" : : "m"(*data)); break;
 #ifdef CONFIG_X86_64
-   case 8: asm("movdqu %0, %%xmm8" : : "m"(*data)); break;
-   case 9: asm("movdqu %0, %%xmm9" : : "m"(*data)); break;
-   case 10: asm("movdqu %0, %%xmm10" : : "m"(*data)); break;
-   case 11: asm("movdqu %0, %%xmm11" : : "m"(*data)); break;
-   case 12: asm("movdqu %0, %%xmm12" : : "m"(*data)); break;
-   case 13: asm("movdqu %0, %%xmm13" : : "m"(*data)); break;
-   case 14: asm("movdqu %0, %%xmm14" : : "m"(*data)); break;
-   case 15: asm("movdqu %0, %%xmm15" : : "m"(*data)); break;
+   case 8: asm("movdqa %0, %%xmm8" : : "m"(*data)); break;
+   case 9: asm("movdqa %0, %%xmm9" : : "m"(*data)); break;
+   case 10: asm("movdqa %0, %%xmm10" : : "m"(*data)); break;
+   case 11: asm("movdqa %0, %%xmm11" : : "m"(*data)); break;
+   case 12: asm("movdqa %0, %%xmm12" : : "m"(*data)); break;
+   case 13: asm("movdqa %0, %%xmm13" : : "m"(*data)); break;
+   case 14: asm("movdqa %0, %%xmm14" : : "m"(*data)); break;
+   case 15: asm("movdqa %0, %%xmm15" : : 

[PATCH 8/8] KVM: SVM: constify lookup tables

[Mathias Krause]

We never modify direct_access_msrs[], msrpm_ranges[],
svm_exit_handlers[] or x86_intercept_map[] at runtime.
Mark them r/o.

Signed-off-by: Mathias Krause 
Cc: Joerg Roedel 
---
 arch/x86/kvm/svm.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 31be4a5..611c728 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -163,7 +163,7 @@ static DEFINE_PER_CPU(u64, current_tsc_ratio);
 
 #define MSR_INVALID0xU
 
-static struct svm_direct_access_msrs {
+static const struct svm_direct_access_msrs {
u32 index;   /* Index of the MSR */
bool always; /* True if intercept is always on */
 } direct_access_msrs[] = {
@@ -400,7 +400,7 @@ struct svm_init_data {
int r;
 };
 
-static u32 msrpm_ranges[] = {0, 0xc000, 0xc001};
+static const u32 msrpm_ranges[] = {0, 0xc000, 0xc001};
 
 #define NUM_MSR_MAPS ARRAY_SIZE(msrpm_ranges)
 #define MSRS_RANGE_SIZE 2048
@@ -3267,7 +3267,7 @@ static int pause_interception(struct vcpu_svm *svm)
return 1;
 }
 
-static int (*svm_exit_handlers[])(struct vcpu_svm *svm) = {
+static int (*const svm_exit_handlers[])(struct vcpu_svm *svm) = {
[SVM_EXIT_READ_CR0] = cr_interception,
[SVM_EXIT_READ_CR3] = cr_interception,
[SVM_EXIT_READ_CR4] = cr_interception,
@@ -4068,7 +4068,7 @@ static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
 #define POST_MEM(exit) { .exit_code = (exit), \
.stage = X86_ICPT_POST_MEMACCESS, }
 
-static struct __x86_intercept {
+static const struct __x86_intercept {
u32 exit_code;
enum x86_intercept_stage stage;
 } x86_intercept_map[] = {
-- 
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/

[PATCH 7/8] KVM: VMX: constify lookup tables

[Mathias Krause]

We use vmcs_field_to_offset_table[], kvm_vmx_segment_fields[] and
kvm_vmx_exit_handlers[] as lookup tables only -- make them r/o.

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/vmx.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 248c2b4..d62b413 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -450,7 +450,7 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu *vcpu)
 #define FIELD64(number, name)  [number] = VMCS12_OFFSET(name), \
[number##_HIGH] = VMCS12_OFFSET(name)+4
 
-static unsigned short vmcs_field_to_offset_table[] = {
+static const unsigned short vmcs_field_to_offset_table[] = {
FIELD(VIRTUAL_PROCESSOR_ID, virtual_processor_id),
FIELD(GUEST_ES_SELECTOR, guest_es_selector),
FIELD(GUEST_CS_SELECTOR, guest_cs_selector),
@@ -666,7 +666,7 @@ static struct vmx_capability {
.ar_bytes = GUEST_##seg##_AR_BYTES, \
}
 
-static struct kvm_vmx_segment_field {
+static const struct kvm_vmx_segment_field {
unsigned selector;
unsigned base;
unsigned limit;
@@ -2695,7 +2695,7 @@ static __exit void hardware_unsetup(void)
 
 static void fix_pmode_dataseg(struct kvm_vcpu *vcpu, int seg, struct 
kvm_segment *save)
 {
-   struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
+   const struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
struct kvm_segment tmp = *save;
 
if (!(vmcs_readl(sf->base) == tmp.base && tmp.s)) {
@@ -2764,7 +2764,7 @@ static gva_t rmode_tss_base(struct kvm *kvm)
 
 static void fix_rmode_seg(int seg, struct kvm_segment *save)
 {
-   struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
+   const struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
 
vmcs_write16(sf->selector, save->base >> 4);
vmcs_write32(sf->base, save->base & 0x0);
@@ -3202,7 +3202,7 @@ static void vmx_set_segment(struct kvm_vcpu *vcpu,
struct kvm_segment *var, int seg)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
-   struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
+   const struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
u32 ar;
 
vmx_segment_cache_clear(vmx);
@@ -3572,7 +3572,7 @@ out:
 
 static void seg_setup(int seg)
 {
-   struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
+   const struct kvm_vmx_segment_field *sf = _vmx_segment_fields[seg];
unsigned int ar;
 
vmcs_write16(sf->selector, 0);
@@ -5655,7 +5655,7 @@ static int handle_vmptrst(struct kvm_vcpu *vcpu)
  * may resume.  Otherwise they set the kvm_run parameter to indicate what needs
  * to be done to userspace and return 0.
  */
-static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
+static int (*const kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
[EXIT_REASON_EXCEPTION_NMI]   = handle_exception,
[EXIT_REASON_EXTERNAL_INTERRUPT]  = handle_external_interrupt,
[EXIT_REASON_TRIPLE_FAULT]= handle_triple_fault,
-- 
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/

[PATCH 6/8] KVM: x86: more constification

[Mathias Krause]

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/lapic.c |2 +-
 arch/x86/kvm/x86.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 18d149d..07ad628 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -198,7 +198,7 @@ static inline int apic_x2apic_mode(struct kvm_lapic *apic)
return apic->vcpu->arch.apic_base & X2APIC_ENABLE;
 }
 
-static unsigned int apic_lvt_mask[APIC_LVT_NUM] = {
+static const unsigned int apic_lvt_mask[APIC_LVT_NUM] = {
LVT_MASK ,  /* part LVTT mask, timer mode mask added at runtime */
LVT_MASK | APIC_MODE_MASK,  /* LVTTHMR */
LVT_MASK | APIC_MODE_MASK,  /* LVTPC */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 79ac03c..d981008 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -817,7 +817,7 @@ static u32 msrs_to_save[] = {
 
 static unsigned num_msrs_to_save;
 
-static u32 emulated_msrs[] = {
+static const u32 emulated_msrs[] = {
MSR_IA32_TSCDEADLINE,
MSR_IA32_MISC_ENABLE,
MSR_IA32_MCG_STATUS,
-- 
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/

[PATCH 5/8] KVM: x86: constify read_write_emulator_ops

[Mathias Krause]

We never change those, make them r/o.

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/x86.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f8b0148..79ac03c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3773,14 +3773,14 @@ static int write_exit_mmio(struct kvm_vcpu *vcpu, gpa_t 
gpa,
return X86EMUL_CONTINUE;
 }
 
-static struct read_write_emulator_ops read_emultor = {
+static const struct read_write_emulator_ops read_emultor = {
.read_write_prepare = read_prepare,
.read_write_emulate = read_emulate,
.read_write_mmio = vcpu_mmio_read,
.read_write_exit_mmio = read_exit_mmio,
 };
 
-static struct read_write_emulator_ops write_emultor = {
+static const struct read_write_emulator_ops write_emultor = {
.read_write_emulate = write_emulate,
.read_write_mmio = write_mmio,
.read_write_exit_mmio = write_exit_mmio,
@@ -3791,7 +3791,7 @@ static int emulator_read_write_onepage(unsigned long 
addr, void *val,
   unsigned int bytes,
   struct x86_exception *exception,
   struct kvm_vcpu *vcpu,
-  struct read_write_emulator_ops *ops)
+  const struct read_write_emulator_ops 
*ops)
 {
gpa_t gpa;
int handled, ret;
@@ -3840,7 +3840,7 @@ mmio:
 int emulator_read_write(struct x86_emulate_ctxt *ctxt, unsigned long addr,
void *val, unsigned int bytes,
struct x86_exception *exception,
-   struct read_write_emulator_ops *ops)
+   const struct read_write_emulator_ops *ops)
 {
struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
gpa_t gpa;
-- 
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/

[PATCH 4/8] KVM: x86: constify emulate_ops

[Mathias Krause]

We never change emulate_ops[] at runtime so it should be r/o.

Signed-off-by: Mathias Krause 
---
 arch/x86/include/asm/kvm_emulate.h |2 +-
 arch/x86/kvm/emulate.c |   22 +++---
 arch/x86/kvm/x86.c |2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index 282aee5..b5bb73a 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -250,7 +250,7 @@ struct read_cache {
 };
 
 struct x86_emulate_ctxt {
-   struct x86_emulate_ops *ops;
+   const struct x86_emulate_ops *ops;
 
/* Register state before/after emulation. */
unsigned long eflags;
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index fd06f9d..663e958 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1325,7 +1325,7 @@ static int read_interrupt_descriptor(struct 
x86_emulate_ctxt *ctxt,
 static void get_descriptor_table_ptr(struct x86_emulate_ctxt *ctxt,
 u16 selector, struct desc_ptr *dt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
 
if (selector & 1 << 2) {
struct desc_struct desc;
@@ -1747,7 +1747,7 @@ static int em_popa(struct x86_emulate_ctxt *ctxt)
 
 static int __emulate_int_real(struct x86_emulate_ctxt *ctxt, int irq)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
int rc;
struct desc_ptr dt;
gva_t cs_addr;
@@ -2129,7 +2129,7 @@ static bool vendor_intel(struct x86_emulate_ctxt *ctxt)
 
 static bool em_syscall_is_enabled(struct x86_emulate_ctxt *ctxt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
u32 eax, ebx, ecx, edx;
 
/*
@@ -2173,7 +2173,7 @@ static bool em_syscall_is_enabled(struct x86_emulate_ctxt 
*ctxt)
 
 static int em_syscall(struct x86_emulate_ctxt *ctxt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct desc_struct cs, ss;
u64 msr_data;
u16 cs_sel, ss_sel;
@@ -2231,7 +2231,7 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt)
 
 static int em_sysenter(struct x86_emulate_ctxt *ctxt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct desc_struct cs, ss;
u64 msr_data;
u16 cs_sel, ss_sel;
@@ -2294,7 +2294,7 @@ static int em_sysenter(struct x86_emulate_ctxt *ctxt)
 
 static int em_sysexit(struct x86_emulate_ctxt *ctxt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct desc_struct cs, ss;
u64 msr_data;
int usermode;
@@ -2357,7 +2357,7 @@ static bool emulator_bad_iopl(struct x86_emulate_ctxt 
*ctxt)
 static bool emulator_io_port_access_allowed(struct x86_emulate_ctxt *ctxt,
u16 port, u16 len)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct desc_struct tr_seg;
u32 base3;
int r;
@@ -2476,7 +2476,7 @@ static int task_switch_16(struct x86_emulate_ctxt *ctxt,
  u16 tss_selector, u16 old_tss_sel,
  ulong old_tss_base, struct desc_struct *new_desc)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct tss_segment_16 tss_seg;
int ret;
u32 new_tss_base = get_desc_base(new_desc);
@@ -2623,7 +2623,7 @@ static int task_switch_32(struct x86_emulate_ctxt *ctxt,
  u16 tss_selector, u16 old_tss_sel,
  ulong old_tss_base, struct desc_struct *new_desc)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct tss_segment_32 tss_seg;
int ret;
u32 new_tss_base = get_desc_base(new_desc);
@@ -2667,7 +2667,7 @@ static int emulator_do_task_switch(struct 
x86_emulate_ctxt *ctxt,
   u16 tss_selector, int idt_index, int reason,
   bool has_error_code, u32 error_code)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
struct desc_struct curr_tss_desc, next_tss_desc;
int ret;
u16 old_tss_sel = get_segment_selector(ctxt, VCPU_SREG_TR);
@@ -4339,7 +4339,7 @@ static void fetch_possible_mmx_operand(struct 
x86_emulate_ctxt *ctxt,
 
 int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
 {
-   struct x86_emulate_ops *ops = ctxt->ops;
+   const struct x86_emulate_ops *ops = ctxt->ops;
int rc = X86EMUL_CONTINUE;
int saved_dst_type = ctxt->dst.type;
 
diff 

[PATCH 0/8] KVM: minor cleanups and optimizations

[Mathias Krause]

Hi Avi, Marcelo

this patch series implements a few micro optimizations for the x86 KVM
code base. The two major changes are constification of variables and an
optimization for the SSE emulation. The former gives the compiler more
opportunities for optimizations and ensures the r/o data is not put in
a cache line together with data that gets written to. The latter should
speed up the emulation of SSE register moves as the aligned variant of
MOVDQ has lower latencies and higher throughput than the unaligned one.

Regards,

Mathias Krause (8):
  KVM: x86: minor size optimization
  KVM: x86 emulator: use aligned variants of SSE register ops
  KVM: x86: mark opcode tables const
  KVM: x86: constify emulate_ops
  KVM: x86: constify read_write_emulator_ops
  KVM: x86: more constification
  KVM: VMX: constify lookup tables
  KVM: SVM: constify lookup tables

 arch/x86/include/asm/kvm_emulate.h |2 +-
 arch/x86/kvm/cpuid.c   |   12 ++--
 arch/x86/kvm/emulate.c |  126 ++--
 arch/x86/kvm/lapic.c   |2 +-
 arch/x86/kvm/svm.c |8 +--
 arch/x86/kvm/vmx.c |   14 ++--
 arch/x86/kvm/x86.c |   12 ++--
 7 files changed, 88 insertions(+), 88 deletions(-)

-- 
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/

[PATCH 1/8] KVM: x86: minor size optimization

[Mathias Krause]

Some fields can be constified and/or made static to reduce code and data
size.

Numbers for a 32 bit build:

textdata bss dec hex filename
before: 3351  80   03431 d67 cpuid.o
 after: 3391   0   03391 d3f cpuid.o

Signed-off-by: Mathias Krause 
---
 arch/x86/kvm/cpuid.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index b496da6..ec79e77 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -397,8 +397,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 
function,
break;
}
case KVM_CPUID_SIGNATURE: {
-   char signature[12] = "KVMKVMKVM\0\0";
-   u32 *sigptr = (u32 *)signature;
+   static const char signature[12] = "KVMKVMKVM\0\0";
+   const u32 *sigptr = (const u32 *)signature;
entry->eax = KVM_CPUID_FEATURES;
entry->ebx = sigptr[0];
entry->ecx = sigptr[1];
@@ -484,10 +484,10 @@ struct kvm_cpuid_param {
u32 func;
u32 idx;
bool has_leaf_count;
-   bool (*qualifier)(struct kvm_cpuid_param *param);
+   bool (*qualifier)(const struct kvm_cpuid_param *param);
 };
 
-static bool is_centaur_cpu(struct kvm_cpuid_param *param)
+static bool is_centaur_cpu(const struct kvm_cpuid_param *param)
 {
return boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR;
 }
@@ -498,7 +498,7 @@ int kvm_dev_ioctl_get_supported_cpuid(struct kvm_cpuid2 
*cpuid,
struct kvm_cpuid_entry2 *cpuid_entries;
int limit, nent = 0, r = -E2BIG, i;
u32 func;
-   static struct kvm_cpuid_param param[] = {
+   static const struct kvm_cpuid_param param[] = {
{ .func = 0, .has_leaf_count = true },
{ .func = 0x8000, .has_leaf_count = true },
{ .func = 0xC000, .qualifier = is_centaur_cpu, 
.has_leaf_count = true },
@@ -517,7 +517,7 @@ int kvm_dev_ioctl_get_supported_cpuid(struct kvm_cpuid2 
*cpuid,
 
r = 0;
for (i = 0; i < ARRAY_SIZE(param); i++) {
-   struct kvm_cpuid_param *ent = [i];
+   const struct kvm_cpuid_param *ent = [i];
 
if (ent->qualifier && !ent->qualifier(ent))
continue;
-- 
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/

Using uio_pdrv to create an platform device for an FPGA, mmap() fails

[Worth, Kevin]

I have below what appears to be a mostly-functional device using the UIO 
Platform Driver. The /sys entries I'd expect appear,  /proc/iomem contains " 
d000-dfff : myfpga", and lsuio sees the properties that I've set. 
However an mmap() from userspace (either my test program below or lsuio) fails. 
So close! (at least it would seem)

Finding a good example for this did not come easily (which is why I'm hitting 
LKML, since I know it'll get a lot of eyeballs and be archived). Maybe there 
was something obvious I missed, but the only "official" documentation I could 
locate was http://www.kernel.org/doc/htmldocs/uio-howto.html#using_uio_pdrv , 
and most everything else was snippets from presentations, papers, and forums 
that lacked completeness.

Thanks for the help any might be able to offer.
Please CC me on replies as I'm not ready to drink from the fire hose that is an 
LKML subscription.

# lsuio -v -m
uio0: name=uio_myfpga, version=0.1, events=0
map[0]: addr=0xD000, size=4096, mmap test: FAILED
Device attributes:
uevent=DRIVER=uio_pdrv
modalias=platform:uio_pdrv

--Kernelspace portion---

#include 
#include 
#include 

#define MYFPGA_BASE 0xd000 // 3G
#define MYFPGA_SIZE 0x0004 // 256k

static struct resource myfpga_resources[] = {
{
.start  = MYFPGA_BASE,
.end= MYFPGA_BASE + MYFPGA_SIZE - 1,
.name   = "myfpga",
.flags  = IORESOURCE_MEM
}
};

static struct uio_info myfpga_uio_info = {
   .name = "uio_myfpga",
   .version = "0.1",
   .irq = UIO_IRQ_CUSTOM,
   .mem = {
{
.name = "myfpga",
.memtype = UIO_MEM_PHYS,
.addr = MYFPGA_BASE,
.size = MYFPGA_SIZE
}
}
};

static struct platform_device_info myfpga_uio_pdevinfo = {
.name = "uio_pdrv",
.id = -1,
.res = myfpga_resources,
.num_res = 1,
.data = _uio_info,
.size_data = sizeof(struct uio_info)
};

static struct platform_device *myfpga_uio_pdev;

static int __init myfpga_init(void)
{
myfpga_uio_pdev = platform_device_register_full(_uio_pdevinfo);
if (IS_ERR(myfpga_uio_pdev)) {
return PTR_ERR(myfpga_uio_pdev);
}

return 0;
}

static void __exit myfpga_exit(void)
{
platform_device_unregister(myfpga_uio_pdev);
}

module_init(myfpga_init);
module_exit(myfpga_exit);

--Userspace portion---

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#define MYFPGA_BASE 0xd000 // 3G
#define MYFPGA_SIZE 0x0004 // 256k
#define MYFPGA_UIO_NUM  0  // uio0

int main (int argc, char *argv[])
{
int fd;
void *iomem;
fd = open("/dev/uio0", O_RDWR|O_SYNC);
if (fd < 0) {
printf("failed to open /dev/uio0, quitting\n");
return -1;
}
/* Note offset has a special meaning with uio devices */
iomem = mmap(NULL, MYFPGA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
 MYFPGA_UIO_NUM * getpagesize());
if (iomem == MAP_FAILED) {
printf("mmap failed, quitting\n");
close(fd);
return -2;
}
printf("mmap successful!\n");
munmap(iomem, MYFPGA_SIZE);
close(fd);
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: Drop support for x86-32

[Mark Lord]

On 12-08-26 10:15 AM, wbrana wrote:
> On 8/26/12, Mark Lord  wrote:
>> Here are a couple of real scenarios you don't seem to have thought about.
>> A 32-bit kernel on a legacy (or even new) system in 2017 will still need
>> regular kernel updates (not "long term" un0maintained kernels)
>> in order to work with new USB devices, new 4KB+ sector hard drives,
>> newer generations of SSDs, etc..
> 12-years-old machine is trash.

There you go making assumptions again.
Who said anything about a 12-year old machine?

Much more likely is a 5-year old software installation
that gets moved to a new box.


--
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 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Michael S. Tsirkin]

On Wed, Aug 29, 2012 at 10:46:19PM +0200, Sasha Levin wrote:
> On 08/29/2012 08:12 PM, Michael S. Tsirkin wrote:
> >>> > > What is a good default for net? I guess max sg?
> >> > 
> >> > I think that it depends on the workload. I'd say we should keep the 
> >> > default to 0
> >> > (disabled) unless we can have a good way to adjust it to the load.
> > For *all* drivers?
> > 
> > Then it is mostly useless. No one has the time to tweak module
> > parameters in real life.
> > 
> > For virtio-net, 16+1 is not too much and ensures we always
> > use the cache.
> > 
> > If that works better than 0 I would say run with 17.
> 
> I was being extra-cautious with leaving it disabled until specifically enabled
> because I assumed that this would be one of the first comments I'll get if it
> was enabled by default :)
> 
> If you're comfortable with setting it to a sane default like 17, I'm perfectly
> fine with that as well.
> 
> 
> Thanks,
> Sasha

If our testing shows it helps and does not trigger regressions, then
why not? module params are mostly there for developers.
They are not all that helpful to users.

> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/13] overlayfs: add statfs support

[Miklos Szeredi]

Ben Hutchings  writes:

> On Wed, Aug 15, 2012 at 05:48:12PM +0200, Miklos Szeredi wrote:
>> From: Andy Whitcroft 
>> 
>> Add support for statfs to the overlayfs filesystem.  As the upper layer
>> is the target of all write operations assume that the space in that
>> filesystem is the space in the overlayfs.  There will be some inaccuracy as
>> overwriting a file will copy it up and consume space we were not expecting,
>> but it is better than nothing.
>> 
>> Use the upper layer dentry and mount from the overlayfs root inode,
>> passing the statfs call to that filesystem.
> [...] 
>> +/**
>> + * ovl_statfs
>> + * @sb: The overlayfs super block
>> + * @buf: The struct kstatfs to fill in with stats
>> + *
>> + * Get the filesystem statistics.  As writes always target the upper layer
>> + * filesystem pass the statfs to the same filesystem.
>> + */
>> +static int ovl_statfs(struct dentry *dentry, struct kstatfs *buf)
>> +{
>> +struct dentry *root_dentry = dentry->d_sb->s_root;
>> +struct path path;
>> +ovl_path_upper(root_dentry, );
>> +
>> +if (!path.dentry->d_sb->s_op->statfs)
>> +return -ENOSYS;
>> +return path.dentry->d_sb->s_op->statfs(path.dentry, buf);
>> +}
> [...]
>
> In case f_namelen differs between the upper and lower filesystems, you
> need to return the greater of the two.

Maybe.  I've never seen any app use f_namelen for anything useful.

>
> Should f_type be overridden to indicate overlayfs?  I'm not sure what
> userland is likely to do with f_type.  (For presentation to the user,
> it should get the mount type name with getmntent() or libmount.  And
> that will just work.)

Yeah we could do that.

Thanks,
Miklos
--
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: WARNING: at fs/inode.c:280 drop_nlink+0x31/0x33()

[Jeff Layton]

On Wed, 29 Aug 2012 09:25:27 -0700
Nick Pasich  wrote:

> 
> I'm using kernel 3.5.3 ... 
> 
> It happens on 3.5.1 and 3.5.2 also.
> 
> I know that Nick Bowler has already reported this...
> 
> I'm experiencing the same thing.
> 
> It happens when moving files from one directory to another
> on the same partition (NFS). 
> 
>   --( Nick Pasich )--
> 
> 
> #
> ##
> ## Happens when PSTs are moved from one directory to another on the ISCSI ...
> ##
> #
> 
> Aug 29 08:06:16 localhost kernel: [ cut here ]
> Aug 29 08:06:16 localhost kernel: WARNING: at fs/inode.c:280 
> drop_nlink+0x31/0x33()
> Aug 29 08:06:16 localhost kernel: Hardware name: To Be Filled By O.E.M.
> Aug 29 08:06:16 localhost kernel: Modules linked in: ecb md4 cifs w83627hf 
> eeprom asb100 hwmon_vid hwmon nfsd exportfs ipv6 psmouse usb_storage 
> io_edgeport usbserial sg r8169 mii evdev intel_agp uhci_hcd i2c_i801 i2c_core 
> shpchp intel_gtt agpgart ehci_hcd microcode serio_raw
> Aug 29 08:06:16 localhost kernel: Pid: 31477, comm: rm Tainted: GW
> 3.5.3 #1
> Aug 29 08:06:16 localhost kernel: Call Trace:
> Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> Aug 29 08:06:16 localhost kernel:  [] ? 
> warn_slowpath_common+0x7b/0x90
> Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> Aug 29 08:06:16 localhost kernel:  [] ? warn_slowpath_null+0x1b/0x1f
> Aug 29 08:06:16 localhost kernel:  [] ? drop_nlink+0x31/0x33
> Aug 29 08:06:16 localhost kernel:  [] ? cifs_unlink+0x134/0x63d 
> [cifs]
> Aug 29 08:06:16 localhost kernel:  [] ? dput+0x11/0x117
> Aug 29 08:06:16 localhost kernel:  [] ? mntput_no_expire+0xf/0xf7
> Aug 29 08:06:16 localhost kernel:  [] ? vfs_unlink+0x4e/0xb6
> Aug 29 08:06:16 localhost kernel:  [] ? __lookup_hash+0x54/0xac
> Aug 29 08:06:16 localhost kernel:  [] ? do_unlinkat+0x10a/0x12d
> Aug 29 08:06:16 localhost kernel:  [] ? sys_ioctl+0x34/0x57
> Aug 29 08:06:16 localhost kernel:  [] ? syscall_call+0x7/0xb
> Aug 29 08:06:16 localhost kernel: ---[ end trace 756b427e3bd671f9 ]---
> 

(cc'ing linux-cifs ml)

This stack trace comes from cifs, not nfs.

Steve French has a patch queued in his tree to silence this warning
that I believe he intends to send to Linus for 3.6. Perhaps we should
consider backporting it for 3.5.z too?

-- 
Jeff Layton 
--
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] staging: zcache: fix cleancache race condition with shrinker

[Seth Jennings]

This patch fixes a race condition that results in memory
corruption when using cleancache.

The race exists between the zcache shrinker handler,
shrink_zcache_memory() and cleancache_get_page().

In most cases, the shrinker will both evict a zbpg
from its buddy list and flush it from tmem before a
cleancache_get_page() occurs on that page. A subsequent
cleancache_get_page() will fail in the tmem layer.

In the rare case that two occur together and the
cleancache_get_page() path gets through the tmem
layer before the shrinker path can flush tmem,
zbud_decompress() does a check to see if the zbpg is a
"zombie", i.e. not on a buddy list, which means the shrinker
is in the process of reclaiming it. If the zbpg is a zombie,
zbud_decompress() returns -EINVAL.

However, this return code is being ignored by the caller,
zcache_pampd_get_data_and_free(), which results in the
caller of cleancache_get_page() thinking that the page has
been properly retrieved when it has not.

This patch modifies zcache_pampd_get_data_and_free() to
convey the failure up the stack so that the caller of
cleancache_get_page() knows the page retrieval failed.

---
Based on v3.6-rc3.

This needs to be applied to stable trees as well.
zcache-main.c was named zcache.c before v3.1, so
I'm not sure how you want to handle trees earlier
than that.

Signed-off-by: Seth Jennings 
---
 drivers/staging/zcache/zcache-main.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c 
b/drivers/staging/zcache/zcache-main.c
index c214977..52b43b7 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -1251,13 +1251,12 @@ static int zcache_pampd_get_data_and_free(char *data, 
size_t *bufsize, bool raw,
void *pampd, struct tmem_pool *pool,
struct tmem_oid *oid, uint32_t index)
 {
-   int ret = 0;
-
BUG_ON(!is_ephemeral(pool));
-   zbud_decompress((struct page *)(data), pampd);
+   if (zbud_decompress((struct page *)(data), pampd) < 0)
+   return -EINVAL;
zbud_free_and_delist((struct zbud_hdr *)pampd);
atomic_dec(_curr_eph_pampd_count);
-   return ret;
+   return 0;
 }
 
 /*
-- 
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/

Storage regression in v3.6-rc3 was: Storage related regression in linux-next 20120824

[Dieter Ries]

Hi again,

On 08/27/2012 06:39 PM, Dieter Ries wrote:
> On 08/27/2012 04:40 PM, Jeff Garzik wrote:
>> On Mon, Aug 27, 2012 at 4:59 AM, Arvydas Sidorenko  wrote:
>>> linux-next 20120824 introduced regression on Mac mini 2011 - /root partition
>>> gets mounted as read-only and it stays so even when trying to reboot into
>>> previously working kernel. In order to make it work on older kernel again
>>> `fsck` needs to be executed:
>>> --
>>> Root partition uses ext4 filesystem on Intel 330 SSD connected to SATA3.
>>> dmesg shows that journaling was disabled:
>>> --
>>> I haven't bisected to which exactly tree introduces the regression,
>>> but I can tell
>>> that linux-next 20120813 and v3.6-rc3 work fine.
> 
> I think I experienced this with v3.6-rc3 today as well. I thought my ssd
> (ocz vertex3) was broken first, but then I saw this mail.
> 
> Never happened before on 3.5.something.
> 
> I am trying to reproduce it right now, it happened 2 times before I read
> the mail, I didnt keep the dmesg. Now it's taking it's time to occurr
> again...

It happened again today, and I managed to get a dmesg this time. The
root partition was first, which results in the dmesg you can find
attached. Later the same happened to the home partition, but then I
wasn't able to save a dmesg anymore.

Just to stress this again, this mangles my root partition, resulting in
another forced reboot for fixing it again after a reboot. So I guess
it's possibly dangerous.

It never happened on other kernels, and with 3.6-rc3 it happened on 3
partitions now, as I copied the content of the root partition to
somewhere else on the ssd after it happened first.

>> Can you pastebin 'dmesg' and 'lspci'?  Did this occur only once, or is
>> it reproducible?

Both are attached. I cannot really bisect it, because I cannot trigger
it. It just happens at inconvenien moments...

One funny thing is: The lspci output was different between one boot
where nothing happened, and today after it happened agian. Only 2
revisions changed, but I attached both anyway, the one suffixed "Bad" is
after the problem occured.

>>  Jeff

Cheers,

Dieter

>> --
>> 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/
>>
> 
> 

[0.400346] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[0.400686] NET: Registered protocol family 1
[0.400826] pci :00:02.0: Boot video device
[0.401127] PCI: CLS 64 bytes, default 64
[0.401160] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[0.401254] software IO TLB [mem 0xd6995000-0xda994fff] (64MB) mapped at 
[8800d6995000-8800da994fff]
[0.404125] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x17
[0.404228] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x17
[0.404330] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x17
[0.404437] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x17
[0.404682] microcode: Microcode Update Driver: v2.00 
, Peter Oruba
[0.405546] audit: initializing netlink socket (disabled)
[0.405656] type=2000 audit(1346226458.281:1): initialized
[0.407750] VFS: Disk quotas dquot_6.5.2
[0.407921] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[0.408512] NTFS driver 2.1.30 [Flags: R/W].
[0.408656] fuse init (API version 7.20)
[0.409195] SGI XFS with ACLs, security attributes, realtime, large 
block/inode numbers, no debug enabled
[0.409722] OCFS2 1.5.0
[0.409948] ocfs2: Registered cluster interface o2cb
[0.410035] OCFS2 DLMFS 1.5.0
[0.410189] OCFS2 User DLM kernel interface loaded
[0.410277] OCFS2 Node Manager 1.5.0
[0.410616] OCFS2 DLM 1.5.0
[0.411049] Btrfs loaded
[0.411456] GFS2 installed
[0.411546] msgmni has been set to 15750
[0.412221] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
254)
[0.412336] io scheduler noop registered
[0.412420] io scheduler deadline registered (default)
[0.412535] io scheduler cfq registered
[0.414252] intel_idle: MWAIT substates: 0x21120
[0.414258] intel_idle: v0.4 model 0x2A
[0.414261] intel_idle: lapic_timer_reliable_states 0x
[0.414541] ACPI: Deprecated procfs I/F for AC is loaded, please retry with 
CONFIG_ACPI_PROCFS_POWER cleared
[0.415046] ACPI: AC Adapter [AC] (off-line)
[0.415731] input: Lid Switch as 
/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0
[0.416122] ACPI: Lid Switch [LID]
[0.416400] input: Sleep Button as 
/devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input1
[0.418552] ACPI: Sleep Button [SLPB]
[0.418883] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[0.419003] ACPI: Power 

Re: [PATCH] clk: Make the generic clock API available by default

[Stephen Warren]

On 08/28/12 13:35, Mark Brown wrote:

Rather than requiring platforms to select the generic clock API to make
it available make the API available as a user selectable option unless the
user either selects HAVE_CUSTOM_CLK (if they have their own implementation)
or selects COMMON_CLK (if they depend on the generic implementation).

All current architectures that HAVE_CLK but don't use the common clock
framework have selects of HAVE_CUSTOM_CLK added.

This allows drivers to use the generic API on platforms which have no need
for the clock API at platform level.



diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig



@@ -674,6 +676,7 @@ config ARCH_TEGRA
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+   select HAVE_CUSTOM_CLK


For 3.7, Tegra will switch to the common clock framework. I think this 
patch would then disable that. How should we resolve this - rebase the 
Tegra common-clk tree on top of any branch containing this patch in 
order to remove that select statement?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] x86: Only direct map addresses that are marked as E820_RAM

[Jacob Shin]

On Wed, Aug 29, 2012 at 02:17:51PM -0700, Yinghai Lu wrote:
> On Wed, Aug 29, 2012 at 12:04 PM, Jacob Shin  wrote:
> > Currently direct mappings are created for [ 0 to max_low_pfn< > and [ 4GB to max_pfn< > backed by actual DRAM. This is fine for holes under 4GB which are covered
> > by fixed and variable range MTRRs to be UC. However, we run into trouble
> > on higher memory addresses which cannot be covered by MTRRs.
> >
> > Our system with 1TB of RAM has an e820 that looks like this:
> >
> >  BIOS-e820: [mem 0x-0x000983ff] usable
> >  BIOS-e820: [mem 0x00098400-0x0009] reserved
> >  BIOS-e820: [mem 0x000d-0x000f] reserved
> >  BIOS-e820: [mem 0x0010-0xc7eb] usable
> >  BIOS-e820: [mem 0xc7ec-0xc7ed7fff] ACPI data
> >  BIOS-e820: [mem 0xc7ed8000-0xc7ed9fff] ACPI NVS
> >  BIOS-e820: [mem 0xc7eda000-0xc7ff] reserved
> >  BIOS-e820: [mem 0xfec0-0xfec0] reserved
> >  BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> >  BIOS-e820: [mem 0xfff0-0x] reserved
> >  BIOS-e820: [mem 0x0001-0x00e037ff] usable
> >  BIOS-e820: [mem 0x00e03800-0x00fc] reserved
> >  BIOS-e820: [mem 0x0100-0x011ffeff] usable
> >
> > and so direct mappings are created for huge memory hole between
> > 0x00e03800 to 0x0100. Even though the kernel never
> > generates memory accesses in that region, since the page tables mark
> > them incorrectly as being WB, our (AMD) processor ends up causing a MCE
> > while doing some memory bookkeeping/optimizations around that area.
> >
> > This patch iterates through e820 and only direct maps ranges that are
> > marked as E820_RAM, and keeps track of those pfn ranges. Depending on
> > the alignment of E820 ranges, this may possibly result in using smaller
> > size (i.e. 4K instead of 2M or 1G) page tables.
> >
> > Signed-off-by: Jacob Shin 
> > ---
> >  arch/x86/include/asm/page_types.h |9 
> >  arch/x86/kernel/setup.c   |  100 
> > +++--
> >  arch/x86/mm/init.c|2 +
> >  arch/x86/mm/init_64.c |6 +--
> >  4 files changed, 99 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/page_types.h 
> > b/arch/x86/include/asm/page_types.h
> > index e21fdd1..409047a 100644
> > --- a/arch/x86/include/asm/page_types.h
> > +++ b/arch/x86/include/asm/page_types.h
> > @@ -3,6 +3,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  /* PAGE_SHIFT determines the page size */
> >  #define PAGE_SHIFT 12
> > @@ -40,12 +41,20 @@
> >  #endif /* CONFIG_X86_64 */
> >
> >  #ifndef __ASSEMBLY__
> > +#include 
> >
> >  extern int devmem_is_allowed(unsigned long pagenr);
> >
> >  extern unsigned long max_low_pfn_mapped;
> >  extern unsigned long max_pfn_mapped;
> >
> > +extern struct range pfn_mapped[E820_X_MAX];
> > +extern int nr_pfn_mapped;
> > +
> > +extern void add_pfn_range_mapped(unsigned long start_pfn, unsigned long 
> > end_pfn);
> > +extern bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long 
> > end_pfn);
> > +extern bool pfn_is_mapped(unsigned long pfn);
> > +
> >  static inline phys_addr_t get_max_mapped(void)
> >  {
> > return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index d6e8c03..a2e392e 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -115,13 +115,47 @@
> >  #include 
> >
> >  /*
> > - * end_pfn only includes RAM, while max_pfn_mapped includes all e820 
> > entries.
> > - * The direct mapping extends to max_pfn_mapped, so that we can directly 
> > access
> > - * apertures, ACPI and other tables without having to play with fixmaps.
> > + * max_low_pfn_mapped: highest direct mapped pfn under 4GB
> > + * max_pfn_mapped: highest direct mapped pfn over 4GB
> > + *
> > + * The direct mapping only covers E820_RAM regions, so the ranges and gaps 
> > are
> > + * represented by pfn_mapped
> >   */
> >  unsigned long max_low_pfn_mapped;
> >  unsigned long max_pfn_mapped;
> >
> > +struct range pfn_mapped[E820_X_MAX];
> > +int nr_pfn_mapped;
> 
> change to static?

Hm .. yeah I guess we could, the initial reason why I didn't make it
static was because max_pfn_mapped was not static. But I guess as long
as everyone down the line uses pfn_range_is_mapped() to test for direct
mappings, I guess we can change it to static.

> 
> > +
> > +void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
> > +{
> > +   nr_pfn_mapped = add_range_with_merge(pfn_mapped, E820_X_MAX,
> > +nr_pfn_mapped, start_pfn, 
> > end_pfn);
> > +   nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
> > +
> > +   max_pfn_mapped = max(max_pfn_mapped, 

Re: [PATCH 4/6] x86: Only direct map addresses that are marked as E820_RAM

[Borislav Petkov]

On Wed, Aug 29, 2012 at 02:17:51PM -0700, Yinghai Lu wrote:
> > +struct range pfn_mapped[E820_X_MAX];
> > +int nr_pfn_mapped;
> 
> change to static?
> 
> > +
> > +void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
> > +{
> > +   nr_pfn_mapped = add_range_with_merge(pfn_mapped, E820_X_MAX,
> > +nr_pfn_mapped, start_pfn, 
> > end_pfn);
> > +   nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
> > +
> > +   max_pfn_mapped = max(max_pfn_mapped, end_pfn);
> > +
> > +   if (end_pfn <= (1UL << (32 - PAGE_SHIFT)))
> > +   max_low_pfn_mapped = max(max_low_pfn_mapped, end_pfn);
> > +}
> > +
> > +bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < nr_pfn_mapped; i++)
> > +   if ((start_pfn >= pfn_mapped[i].start) &&
> > +   (end_pfn <= pfn_mapped[i].end))
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> > +bool pfn_is_mapped(unsigned long pfn)
> > +{
> > +   return pfn_range_is_mapped(pfn, pfn + 1);
> > +}
> 
> wonder if those functions have to be in arch/x86/kernel/setup.c.
> 
> also do we need to update the tracking array when we have do memory 
> hot-remove?

Would you please make sure you've reviewed this whole patchset
thoroughly so that Jacob can do all changes at once and not keep
resending them twice a week.

Thanks a lot!

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] module: allow loading module from fd

[Kees Cook]

Instead of (or in addition to) kernel module signing, being able to reason
about the origin of a kernel module would be valuable in situations
where an OS already trusts a specific file system, file, etc, due to
things like security labels or an existing root of trust to a partition
through things like dm-verity.

This changes the init_module syscall so that when the first argument
(blob address) is NULL, the second argument is used as a file descriptor
to the module (instead of length). The third argument (module arguments)
remains unchanged.

Some alternatives to overloading the existing syscall are:
 - write a new syscall (seemed unnecessary)
 - add an fd ioctl (awful)
 - enhance the ELF binfmt loader (complex)

It seemed most sensible to avoid introducing new or crazy interfaces
or further complicating the ELF loader. Instead, just use the existing
syscall in a new way. Tools using the fd argument style can trivially
downgrade to the blob argument style when they see an EFAULT error.

Signed-off-by: Kees Cook 
---
 kernel/module.c |   97 +--
 1 files changed, 87 insertions(+), 10 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 4edbd9c..0be8c11 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2399,23 +2400,99 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 }
 #endif
 
-/* Sets info->hdr and info->len. */
-static int copy_and_check(struct load_info *info,
- const void __user *umod, unsigned long len,
- const char __user *uargs)
+static Elf_Ehdr *copy_module_from_user(const void __user *umod,
+  unsigned long len)
 {
-   int err;
Elf_Ehdr *hdr;
 
if (len < sizeof(*hdr))
-   return -ENOEXEC;
+   return ERR_PTR(-ENOEXEC);
 
/* Suck in entire file: we'll want most of it. */
-   if ((hdr = vmalloc(len)) == NULL)
-   return -ENOMEM;
+   hdr = vmalloc(len);
+   if (!hdr)
+   return ERR_PTR(-ENOMEM);
 
if (copy_from_user(hdr, umod, len) != 0) {
-   err = -EFAULT;
+   vfree(hdr);
+   return ERR_PTR(-EFAULT);
+   }
+
+   return hdr;
+}
+
+static Elf_Ehdr *copy_module_from_fd(unsigned int fd, unsigned long *len)
+{
+   struct file *file;
+   int err;
+   Elf_Ehdr *hdr;
+   struct kstat stat;
+   unsigned long size;
+   off_t pos;
+   ssize_t bytes = 0;
+
+   file = fget(fd);
+   if (!file)
+   return ERR_PTR(-ENOEXEC);
+
+   err = vfs_getattr(file->f_vfsmnt, file->f_dentry, );
+   if (err) {
+   hdr = ERR_PTR(err);
+   goto out;
+   }
+
+   if (stat.size > INT_MAX) {
+   hdr = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+   size = stat.size;
+
+   hdr = vmalloc(size);
+   if (!hdr) {
+   hdr = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+
+   pos = 0;
+   while (pos < size) {
+   bytes = kernel_read(file, pos, (char *)hdr + pos, size - pos);
+   if (bytes < 0) {
+   vfree(hdr);
+   hdr = ERR_PTR(bytes);
+   goto out;
+   }
+   if (bytes == 0)
+   break;
+   pos += bytes;
+   }
+   *len = pos;
+
+out:
+   fput(file);
+   return hdr;
+}
+
+/* Sets info->hdr and info->len. */
+static int copy_and_check(struct load_info *info,
+ const void __user *umod, unsigned long len)
+{
+   int err;
+   Elf_Ehdr *hdr;
+
+   if (umod == NULL) {
+   unsigned int fd;
+
+   if (len < 0 || len > INT_MAX)
+   return -ENOEXEC;
+   fd = len;
+
+   hdr = copy_module_from_fd(fd, );
+   } else
+   hdr = copy_module_from_user(umod, len);
+   if (IS_ERR(hdr))
+   return PTR_ERR(hdr);
+   if (len < sizeof(*hdr)) {
+   err = -ENOEXEC;
goto free_hdr;
}
 
@@ -2875,7 +2952,7 @@ static struct module *load_module(void __user *umod,
   umod, len, uargs);
 
/* Copy in the blobs from userspace, check they are vaguely sane. */
-   err = copy_and_check(, umod, len, uargs);
+   err = copy_and_check(, umod, len);
if (err)
return ERR_PTR(err);
 
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] security: introduce kernel_module_from_file hook

[Kees Cook]

Now that kernel module origins can be reasoned about, provide a hook to
the LSMs to make policy decisions about the module file.

Signed-off-by: Kees Cook 
---
 include/linux/security.h |   11 +++
 kernel/module.c  |7 +++
 security/capability.c|6 ++
 security/security.c  |5 +
 4 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index 3dea6a9..634d09a 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -693,6 +693,10 @@ static inline void security_free_mnt_opts(struct 
security_mnt_opts *opts)
  * userspace to load a kernel module with the given name.
  * @kmod_name name of the module requested by the kernel
  * Return 0 if successful.
+ * @kernel_module_from_file:
+ * Load a new kernel module from a file.
+ * @file contains the file structure being loaded as a kernel module.
+ * Return 0 if permission is granted.
  * @task_fix_setuid:
  * Update the module's state after setting one or more of the user
  * identity attributes of the current process.  The @flags parameter
@@ -1507,6 +1511,7 @@ struct security_operations {
int (*kernel_act_as)(struct cred *new, u32 secid);
int (*kernel_create_files_as)(struct cred *new, struct inode *inode);
int (*kernel_module_request)(char *kmod_name);
+   int (*kernel_module_from_file)(struct file *file);
int (*task_fix_setuid) (struct cred *new, const struct cred *old,
int flags);
int (*task_setpgid) (struct task_struct *p, pid_t pgid);
@@ -1764,6 +1769,7 @@ void security_transfer_creds(struct cred *new, const 
struct cred *old);
 int security_kernel_act_as(struct cred *new, u32 secid);
 int security_kernel_create_files_as(struct cred *new, struct inode *inode);
 int security_kernel_module_request(char *kmod_name);
+int security_kernel_module_from_file(struct file *file);
 int security_task_fix_setuid(struct cred *new, const struct cred *old,
 int flags);
 int security_task_setpgid(struct task_struct *p, pid_t pgid);
@@ -2277,6 +2283,11 @@ static inline int security_kernel_module_request(char 
*kmod_name)
return 0;
 }
 
+static inline int security_kernel_module_from_file(struct file *file)
+{
+   return 0;
+}
+
 static inline int security_task_fix_setuid(struct cred *new,
   const struct cred *old,
   int flags)
diff --git a/kernel/module.c b/kernel/module.c
index 0be8c11..1fcc63f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2447,6 +2448,12 @@ static Elf_Ehdr *copy_module_from_fd(unsigned int fd, 
unsigned long *len)
}
size = stat.size;
 
+   err = security_kernel_module_from_file(file);
+   if (err) {
+   hdr = ERR_PTR(err);
+   goto out;
+   }
+
hdr = vmalloc(size);
if (!hdr) {
hdr = ERR_PTR(-ENOMEM);
diff --git a/security/capability.c b/security/capability.c
index 61095df..8acb304 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -395,6 +395,11 @@ static int cap_kernel_module_request(char *kmod_name)
return 0;
 }
 
+static int cap_kernel_module_from_file(struct file *file)
+{
+   return 0;
+}
+
 static int cap_task_setpgid(struct task_struct *p, pid_t pgid)
 {
return 0;
@@ -967,6 +972,7 @@ void __init security_fixup_ops(struct security_operations 
*ops)
set_to_cap_if_null(ops, kernel_act_as);
set_to_cap_if_null(ops, kernel_create_files_as);
set_to_cap_if_null(ops, kernel_module_request);
+   set_to_cap_if_null(ops, kernel_module_from_file);
set_to_cap_if_null(ops, task_fix_setuid);
set_to_cap_if_null(ops, task_setpgid);
set_to_cap_if_null(ops, task_getpgid);
diff --git a/security/security.c b/security/security.c
index 860aeb3..f7f8695 100644
--- a/security/security.c
+++ b/security/security.c
@@ -799,6 +799,11 @@ int security_kernel_module_request(char *kmod_name)
return security_ops->kernel_module_request(kmod_name);
 }
 
+int security_kernel_module_from_file(struct file *file)
+{
+   return security_ops->kernel_module_from_file(file);
+}
+
 int security_task_fix_setuid(struct cred *new, const struct cred *old,
 int flags)
 {
-- 
1.7.0.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 4/6] x86: Only direct map addresses that are marked as E820_RAM

[Yinghai Lu]

On Wed, Aug 29, 2012 at 12:04 PM, Jacob Shin  wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on higher memory addresses which cannot be covered by MTRRs.
>
> Our system with 1TB of RAM has an e820 that looks like this:
>
>  BIOS-e820: [mem 0x-0x000983ff] usable
>  BIOS-e820: [mem 0x00098400-0x0009] reserved
>  BIOS-e820: [mem 0x000d-0x000f] reserved
>  BIOS-e820: [mem 0x0010-0xc7eb] usable
>  BIOS-e820: [mem 0xc7ec-0xc7ed7fff] ACPI data
>  BIOS-e820: [mem 0xc7ed8000-0xc7ed9fff] ACPI NVS
>  BIOS-e820: [mem 0xc7eda000-0xc7ff] reserved
>  BIOS-e820: [mem 0xfec0-0xfec0] reserved
>  BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
>  BIOS-e820: [mem 0xfff0-0x] reserved
>  BIOS-e820: [mem 0x0001-0x00e037ff] usable
>  BIOS-e820: [mem 0x00e03800-0x00fc] reserved
>  BIOS-e820: [mem 0x0100-0x011ffeff] usable
>
> and so direct mappings are created for huge memory hole between
> 0x00e03800 to 0x0100. Even though the kernel never
> generates memory accesses in that region, since the page tables mark
> them incorrectly as being WB, our (AMD) processor ends up causing a MCE
> while doing some memory bookkeeping/optimizations around that area.
>
> This patch iterates through e820 and only direct maps ranges that are
> marked as E820_RAM, and keeps track of those pfn ranges. Depending on
> the alignment of E820 ranges, this may possibly result in using smaller
> size (i.e. 4K instead of 2M or 1G) page tables.
>
> Signed-off-by: Jacob Shin 
> ---
>  arch/x86/include/asm/page_types.h |9 
>  arch/x86/kernel/setup.c   |  100 
> +++--
>  arch/x86/mm/init.c|2 +
>  arch/x86/mm/init_64.c |6 +--
>  4 files changed, 99 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/include/asm/page_types.h 
> b/arch/x86/include/asm/page_types.h
> index e21fdd1..409047a 100644
> --- a/arch/x86/include/asm/page_types.h
> +++ b/arch/x86/include/asm/page_types.h
> @@ -3,6 +3,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /* PAGE_SHIFT determines the page size */
>  #define PAGE_SHIFT 12
> @@ -40,12 +41,20 @@
>  #endif /* CONFIG_X86_64 */
>
>  #ifndef __ASSEMBLY__
> +#include 
>
>  extern int devmem_is_allowed(unsigned long pagenr);
>
>  extern unsigned long max_low_pfn_mapped;
>  extern unsigned long max_pfn_mapped;
>
> +extern struct range pfn_mapped[E820_X_MAX];
> +extern int nr_pfn_mapped;
> +
> +extern void add_pfn_range_mapped(unsigned long start_pfn, unsigned long 
> end_pfn);
> +extern bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long 
> end_pfn);
> +extern bool pfn_is_mapped(unsigned long pfn);
> +
>  static inline phys_addr_t get_max_mapped(void)
>  {
> return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d6e8c03..a2e392e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -115,13 +115,47 @@
>  #include 
>
>  /*
> - * end_pfn only includes RAM, while max_pfn_mapped includes all e820 entries.
> - * The direct mapping extends to max_pfn_mapped, so that we can directly 
> access
> - * apertures, ACPI and other tables without having to play with fixmaps.
> + * max_low_pfn_mapped: highest direct mapped pfn under 4GB
> + * max_pfn_mapped: highest direct mapped pfn over 4GB
> + *
> + * The direct mapping only covers E820_RAM regions, so the ranges and gaps 
> are
> + * represented by pfn_mapped
>   */
>  unsigned long max_low_pfn_mapped;
>  unsigned long max_pfn_mapped;
>
> +struct range pfn_mapped[E820_X_MAX];
> +int nr_pfn_mapped;

change to static?

> +
> +void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +   nr_pfn_mapped = add_range_with_merge(pfn_mapped, E820_X_MAX,
> +nr_pfn_mapped, start_pfn, 
> end_pfn);
> +   nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
> +
> +   max_pfn_mapped = max(max_pfn_mapped, end_pfn);
> +
> +   if (end_pfn <= (1UL << (32 - PAGE_SHIFT)))
> +   max_low_pfn_mapped = max(max_low_pfn_mapped, end_pfn);
> +}
> +
> +bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +   int i;
> +
> +   for (i = 0; i < nr_pfn_mapped; i++)
> +   if ((start_pfn >= pfn_mapped[i].start) &&
> +   (end_pfn <= pfn_mapped[i].end))
> +   return true;
> +
> +   return false;
> +}
> +
> +bool pfn_is_mapped(unsigned long pfn)
> +{
> +   return 

Re: [dm-devel] [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers

[John Stoffel]

> "Kent" == Kent Overstreet  writes:

Kent> On Wed, Aug 29, 2012 at 03:39:14PM +0100, Alasdair G Kergon wrote:
>> It's also instructive to remember why the code is the way it is: it used
>> to process bios for underlying devices immediately, but this sometimes
>> meant too much recursive stack growth.  If a per-device rescuer thread
>> is to be made available (as well as the mempool), the option of
>> reinstating recursion is there too - only punting to workqueue when the
>> stack actually becomes "too big".  (Also bear in mind that some dm
>> targets may have dependencies on their own mempools - submission can
>> block there too.)  I find it helpful only to consider splitting into two
>> pieces - it must always be possible to process the first piece (i.e.
>> process it at the next layer down in the stack) and complete it
>> independently of what happens to the second piece (which might require
>> further splitting and block until the first piece has completed).

Kent> I'm sure it could be made to work (and it may well simpler), but it
Kent> seems problematic from a performance pov.

Kent> With stacked devices you'd then have to switch stacks on _every_ bio.
Kent> That could be made fast enough I'm sure, but it wouldn't be free and I
Kent> don't know of any existing code in the kernel that implements what we'd
Kent> need (though if you know how you'd go about doing that, I'd love to
Kent> know! Would be useful for other things).

Kent> The real problem is that because we'd need these extra stacks for
Kent> handling all bios we couldn't get by with just one per bio_set. We'd
Kent> only need one to make forward progress so the rest could be allocated
Kent> on demand (i.e. what the workqueue code does) but that sounds like it's
Kent> starting to get expensive.

Maybe we need to limit the size of BIOs to that of the bottom-most
underlying device instead?  Or maybe limit BIOs to some small
multiple?  As you stack up DM targets one on top of each other, they
should respect the limits of the underlying devices and pass those
limits up the chain.

Or maybe I'm speaking giberish...

John
--
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: [dm-devel] [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers

[Kent Overstreet]

On Wed, Aug 29, 2012 at 05:01:09PM -0400, John Stoffel wrote:
> > "Kent" == Kent Overstreet  writes:
> 
> Kent> On Wed, Aug 29, 2012 at 03:39:14PM +0100, Alasdair G Kergon wrote:
> >> It's also instructive to remember why the code is the way it is: it used
> >> to process bios for underlying devices immediately, but this sometimes
> >> meant too much recursive stack growth.  If a per-device rescuer thread
> >> is to be made available (as well as the mempool), the option of
> >> reinstating recursion is there too - only punting to workqueue when the
> >> stack actually becomes "too big".  (Also bear in mind that some dm
> >> targets may have dependencies on their own mempools - submission can
> >> block there too.)  I find it helpful only to consider splitting into two
> >> pieces - it must always be possible to process the first piece (i.e.
> >> process it at the next layer down in the stack) and complete it
> >> independently of what happens to the second piece (which might require
> >> further splitting and block until the first piece has completed).
> 
> Kent> I'm sure it could be made to work (and it may well simpler), but it
> Kent> seems problematic from a performance pov.
> 
> Kent> With stacked devices you'd then have to switch stacks on _every_ bio.
> Kent> That could be made fast enough I'm sure, but it wouldn't be free and I
> Kent> don't know of any existing code in the kernel that implements what we'd
> Kent> need (though if you know how you'd go about doing that, I'd love to
> Kent> know! Would be useful for other things).
> 
> Kent> The real problem is that because we'd need these extra stacks for
> Kent> handling all bios we couldn't get by with just one per bio_set. We'd
> Kent> only need one to make forward progress so the rest could be allocated
> Kent> on demand (i.e. what the workqueue code does) but that sounds like it's
> Kent> starting to get expensive.
> 
> Maybe we need to limit the size of BIOs to that of the bottom-most
> underlying device instead?  Or maybe limit BIOs to some small
> multiple?  As you stack up DM targets one on top of each other, they
> should respect the limits of the underlying devices and pass those
> limits up the chain.

That's the approach the block layer currently tries to take. It's
brittle, tricky and inefficient, and it completely breaks down when the
limits are dynamic - so things like dm and bcache are always going to
have to split anyways.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] x86: Fixup code testing if a pfn is direct mapped

[Yinghai Lu]

On Wed, Aug 29, 2012 at 12:04 PM, Jacob Shin  wrote:
> Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
> [ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
> pfn_mapped ranges instead.

please swap patch 5 and patch 4 applying sequence.

aka.
should have
[PATCH 4/6] x86:Fixup code testing if a pfn is direct mapped
and it should have dummy function

bool pfn_range_is_mapped(u64 start_pfn, u64 end_pfn)
{
   return  end_pfn <= max_low_pfn_mapped
   || (end_pfn > (1UL << (32 - PAGE_SHIFT))
   && end_pfn <= max_pfn_mapped);
}

and

[PATCH 5/6] x86: Only direct map addresses that are marked as E820_RAM
will update pfn_range_is_mapped accordingly.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][trivial] gen_init_cpio: remove redundant empty line

[Jesper Juhl]

Just a completely trivial patch to remove a completely redundant blank
line from usr/gen_init_cpio.c

Signed-off-by: Jesper Juhl 
---
 usr/gen_init_cpio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
index af0f22f..b2e46bc 100644
--- a/usr/gen_init_cpio.c
+++ b/usr/gen_init_cpio.c
@@ -402,7 +402,6 @@ static char *cpio_replace_env(char *new_location)
return new_location;
 }
 
-
 static int cpio_mkfile_line(const char *line)
 {
char name[PATH_MAX + 1];
-- 
1.7.12


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
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] net: Providing protocol type via system.sockprotoname xattr of /proc/PID/fd entries

[Masatake YAMATO]

lsof reports some of socket descriptors as "can't identify protocol" like:

[yamato@localhost]/tmp% sudo lsof | grep dbus | grep iden
dbus-daem   652  dbus6u sock ... 17812 can't identify 
protocol
dbus-daem   652  dbus   34u sock ... 24689 can't identify 
protocol
dbus-daem   652  dbus   42u sock ... 24739 can't identify 
protocol
dbus-daem   652  dbus   48u sock ... 22329 can't identify 
protocol
...

lsof cannot resolve the protocol used in a socket because procfs
doesn't provide the map between inode number on sockfs and protocol
type of the socket.

For improving the situation this patch adds an extended attribute named
'system.sockprotoname' in which the protocol name for
/proc/PID/fd/SOCKET is stored. So lsof can know the protocol for a
given /proc/PID/fd/SOCKET with getxattr system call.

A few weeks ago I submitted a patch for the same purpose. The patch
was introduced /proc/net/sockfs which enumerates inodes and protocols
of all sockets alive on a system. However, it was rejected because (1)
a global lock was needed, and (2) the layout of struct socket was
changed with the patch.

This patch doesn't use any global lock; and doesn't change the layout
of any structs.

In this patch, a protocol name is stored to dentry->d_name of sockfs
when new socket is associated with a file descriptor. Before this
patch dentry->d_name was not used; it was just filled with empty
string. lsof may use an extended attribute named
'system.sockprotoname' to retrieve the value of dentry->d_name.

It is nice if we can see the protocol name with ls -l
/proc/PID/fd. However, "socket:[#INODE]", the name format returned
from sockfs_dname() was already defined. To keep the compatibility
between kernel and user land, the extended attribute is used to
prepare the value of dentry->d_name.

Signed-off-by: Masatake YAMATO 
---
 net/socket.c | 83 
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index a5471f8..977c0f4 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -88,6 +88,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -346,7 +347,8 @@ static struct file_system_type sock_fs_type = {
  * but we take care of internal coherence yet.
  */
 
-static int sock_alloc_file(struct socket *sock, struct file **f, int flags)
+static int sock_alloc_file(struct socket *sock, struct file **f, int flags,
+  const char *dname)
 {
struct qstr name = { .name = "" };
struct path path;
@@ -357,6 +359,13 @@ static int sock_alloc_file(struct socket *sock, struct 
file **f, int flags)
if (unlikely(fd < 0))
return fd;
 
+   if (dname) {
+   name.name = dname;
+   name.len = strlen(name.name);
+   } else if (sock->sk) {
+   name.name = sock->sk->sk_prot_creator->name;
+   name.len = strlen(name.name);
+   }
path.dentry = d_alloc_pseudo(sock_mnt->mnt_sb, );
if (unlikely(!path.dentry)) {
put_unused_fd(fd);
@@ -389,7 +398,7 @@ static int sock_alloc_file(struct socket *sock, struct file 
**f, int flags)
 int sock_map_fd(struct socket *sock, int flags)
 {
struct file *newfile;
-   int fd = sock_alloc_file(sock, , flags);
+   int fd = sock_alloc_file(sock, , flags, NULL);
 
if (likely(fd >= 0))
fd_install(fd, newfile);
@@ -455,6 +464,68 @@ static struct socket *sockfd_lookup_light(int fd, int 
*err, int *fput_needed)
return NULL;
 }
 
+#define XATTR_SOCKPROTONAME_SUFFIX "sockprotoname"
+#define XATTR_NAME_SOCKPROTONAME (XATTR_SYSTEM_PREFIX 
XATTR_SOCKPROTONAME_SUFFIX)
+#define XATTR_NAME_SOCKPROTONAME_LEN (sizeof(XATTR_NAME_SOCKPROTONAME)-1)
+static ssize_t sockfs_getxattr(struct dentry *dentry,
+  const char *name, void *value, size_t size)
+{
+   const char *proto_name;
+   size_t proto_size;
+   int error;
+
+   error = -ENODATA;
+   if (!strncmp(name, XATTR_NAME_SOCKPROTONAME, 
XATTR_NAME_SOCKPROTONAME_LEN)) {
+   proto_name = dentry->d_name.name;
+   proto_size = strlen(proto_name);
+
+   if (value) {
+   error = -ERANGE;
+   if (proto_size + 1 > size)
+   goto out;
+
+   strncpy(value, proto_name, proto_size + 1);
+   }
+   error = proto_size + 1;
+   }
+
+out:
+   return error;
+}
+
+static ssize_t sockfs_listxattr(struct dentry *dentry, char *buffer,
+   size_t size)
+{
+   ssize_t len;
+   ssize_t used = 0;
+
+   len = security_inode_listsecurity(dentry->d_inode, buffer, size);
+   if (len < 0)
+   return len;
+   used += len;
+   if (buffer) {
+   if (size < used)
+   

Re: [PATCH v2 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Sasha Levin]

On 08/29/2012 08:12 PM, Michael S. Tsirkin wrote:
>>> > > What is a good default for net? I guess max sg?
>> > 
>> > I think that it depends on the workload. I'd say we should keep the 
>> > default to 0
>> > (disabled) unless we can have a good way to adjust it to the load.
> For *all* drivers?
> 
> Then it is mostly useless. No one has the time to tweak module
> parameters in real life.
> 
> For virtio-net, 16+1 is not too much and ensures we always
> use the cache.
> 
> If that works better than 0 I would say run with 17.

I was being extra-cautious with leaving it disabled until specifically enabled
because I assumed that this would be one of the first comments I'll get if it
was enabled by default :)

If you're comfortable with setting it to a sane default like 17, I'm perfectly
fine with that as well.


Thanks,
Sasha

--
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: KS/Plumbers: c-state governor BOF

[Rik van Riel]

On 08/24/2012 01:01 PM, Rik van Riel wrote:


Since a good number of us will be in San Diego next week, at
Kernel Summit / Plumbers / etc, I will organize a c-state
governor BOF for those who are interested.


Here are the note from today's c-state governor BOF session:

- idle time estimator can be improved to return more
  conservative values
- have a trace point to verify how well idle time estimation works,
  returning expected idle time for the current algorithm, expected
  idle time for a test algorithm, and actually measured idle time
- we can objectively measure whether one idle time estimation
  algorithm is better than another
- example: last 8 idle times are 180 200 30 210 1000 150 1 190
  - average idle time around 1500, but not typical
  - typical idle time just under 200
  - almost all idle time spent in one interval
- scheduler and cpufreq people also want idle time
  statistics, idea is to move the idle time statistics
  to the scheduler
- having idle time statistics in the scheduler allows
  the stats to be migrated when the scheduler migrates
  a task
- interface: expected idle time, demotion time
  - if we sleep much more than the expected idle time, put
CPU into a deeper c-state
  - on x86 timed mwait could be used
  - generic timer code would be usable too
  - take into account both the idle statistics and power break-even




--
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: mxc_nand.c on mach-imx/imx53

[Eric Bénard]

Hi Roland,

Le Wed, 29 Aug 2012 17:20:17 +0200,
Roland Stigge  a écrit :
> Using  ".ecclayout_4k = _hw_eccoob_4k" also doesn't work. So is
> there any hint how I can proceed from here? Any plans or hint regarding
> the "XXX"?
> 
you may need something like this patch from barebox :
http://git.pengutronix.de/?p=barebox.git;a=commit;h=632c45795065e6a7471ab82be38e808eb6204341

I may have time to adapt this next week but if you have time before feel
free to do it ;-)

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: [RFC 0/2] USB gadget - configfs

[Sebastian Andrzej Siewior]

On 08/21/2012 10:19 AM, Andrzej Pietrasiewicz wrote:

@Joel:
However, I am wondering if it would make sense to get rid of the "connect"
(or "ready", if you will) attribute altogether and instead use symlinks:
when a user wants to make the gadget ready, they do an ln -s, when they want
to unbind the gadget they remove the link. What do you think?


I started the "ready" attribue and this symlink sounds reasonable.


There is one more thing to it, I believe; it is how to associate udc's
with gadgets. Perhaps the most convenient way is not needing to do it
explicitly at all: either some udc is found and the gadget is bound to it,


I would prefer explicit binding. Right now first one wins which not
good.


or not. However, I am wondering if something in the spirit of "1984" can
happen: all udcs are equal but some udcs are more equal than others?
So sometimes the user might be interested in binding their gadget to
a particular udc, or at least to a particular kind of udc (no matter
which one if there are more than one of its kind).


Do you have a use case for this? I have a simple one: A phone with two
plugs. You select on the gui storage and network on plug #1 and serial
on plug #2. If you want to obey the selection you have to always know
which UDC ends up on plug #1 and which on #2.
That means the user _always_ wants to bind it to a particular UDC.


And the question
is, whether we want only explicit association with udc, only implicit
association with udc, or both?


/usb-gadget/gadgets/g1
/usb-gadget/udcs/udc1
/usb-gadget/udcs/udc2

and now symlink g1 into udc1 and or udc2

g1 is created by the user and can be named however he wants it to be.
udc1 can be the device name which is unique as well and always the same
thing. It can have a property which distinguish it from udc2 like
memory address or something.



Andrzej


Sebastian
--
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: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

[Francois Romieu]

David Madore  :
[...]
> I imagine it being somehow related to the fact that it operates a
> network bridge (I imagine this because I have another identical
> machine with exactly the same kernel and a very similar config but not
> running a bridge, and the warning never pops up).

Could it not be a genuine allocation failure ?

-- 
Ueimor
--
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: "netpoll: re-enable irq in poll_napi()" breaks boot with netconsole

[Marcin Slusarz]

On Wed, Aug 29, 2012 at 02:59:47PM -0400, David Miller wrote:
> From: Marcin Slusarz 
> Date: Wed, 29 Aug 2012 20:53:29 +0200
> 
> > Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 
> > did.
> > I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d "netpoll:
> > re-enable irq in poll_napi()" and reverting it on top of current Linus' tree
> > restores proper behaviour (disabling netconsole does this too).
> > "Not booting" manifests as immediate hang after network card enabling.
> 
> Fix is already pending, thanks:
> 
> http://patchwork.ozlabs.org/patch/179954/

It works for me. Thanks.

Marcin
--
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 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

[Raghavendra K T]

 The idea of starting from next vcpu (source of yield_to + 1) seem to work
 well for overcomitted guest rather than using last boosted vcpu. We can also
 remove per VM variable with this approach.
 
 Iteration for eligible candidate after this patch starts from vcpu source+1
 and ends at source-1 (after wrapping)
 
 Thanks Nikunj for his quick verification of the patch.
 
 Please let me know if this patch is interesting and makes sense.

8<
From: Raghavendra K T 

 Currently we use next vcpu to last boosted vcpu as starting point
 while deciding eligible vcpu for directed yield.

 In overcomitted scenarios, if more vcpu try to do directed yield,
 they start from same vcpu, resulting in wastage of cpu time (because of
 failing yields and double runqueue lock).
 
 Since probability of same vcpu trying to do directed yield is already
 prevented by improved PLE handler, we can start from next vcpu from source
 of yield_to.

Suggested-by: Srikar Dronamraju 
Signed-off-by: Raghavendra K T 
---

 include/linux/kvm_host.h |1 -
 virt/kvm/kvm_main.c  |   12 
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index b70b48b..64a090d 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -275,7 +275,6 @@ struct kvm {
 #endif
struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
atomic_t online_vcpus;
-   int last_boosted_vcpu;
struct list_head vm_list;
struct mutex lock;
struct kvm_io_bus *buses[KVM_NR_BUSES];
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2468523..65a6c83 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1584,7 +1584,6 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 {
struct kvm *kvm = me->kvm;
struct kvm_vcpu *vcpu;
-   int last_boosted_vcpu = me->kvm->last_boosted_vcpu;
int yielded = 0;
int pass;
int i;
@@ -1594,21 +1593,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 * currently running, because it got preempted by something
 * else and called schedule in __vcpu_run.  Hopefully that
 * VCPU is holding the lock that we need and will release it.
-* We approximate round-robin by starting at the last boosted VCPU.
+* We approximate round-robin by starting at the next VCPU.
 */
for (pass = 0; pass < 2 && !yielded; pass++) {
kvm_for_each_vcpu(i, vcpu, kvm) {
-   if (!pass && i <= last_boosted_vcpu) {
-   i = last_boosted_vcpu;
+   if (!pass && i <= me->vcpu_id) {
+   i = me->vcpu_id;
continue;
-   } else if (pass && i > last_boosted_vcpu)
+   } else if (pass && i >= me->vcpu_id)
break;
-   if (vcpu == me)
-   continue;
if (waitqueue_active(>wq))
continue;
if (kvm_vcpu_yield_to(vcpu)) {
-   kvm->last_boosted_vcpu = i;
yielded = 1;
break;
}

--
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.6-rc3 v2] wlcore: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Declare any firmware that might be used by this driver.
If all drivers declare their firmware usage, then a sufficiently
complete list of firmware files can then be used to pare down
the external linux-firmware package to just the files in actual use.

Cc: Luciano Coelho 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/net/wireless/ti/wlcore/main.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 7254860..a55ace6 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5663,3 +5663,4 @@ MODULE_PARM_DESC(no_recovery, "Prevent HW recovery. FW 
will remain stuck.");
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Luciano Coelho ");
 MODULE_AUTHOR("Juuso Oikarinen ");
+MODULE_FIRMWARE(WL12XX_NVS_NAME);
-- 
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 6/6] x86: if kernel .text .data .bss are not marked as E820_RAM, complain and fix

[Jacob Shin]

There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM, as reported here:

https://lkml.org/lkml/2012/8/14/86

Handle it by complaining, and adding the range back into the e820.

Signed-off-by: Jacob Shin 
---
 arch/x86/kernel/setup.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a2e392e..68f82d2 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -913,6 +913,20 @@ void __init setup_arch(char **cmdline_p)
insert_resource(_resource, _resource);
insert_resource(_resource, _resource);
 
+   /*
+* Complain if .text .data and .bss are not marked as E820_RAM and
+* attempt to fix it by adding the range. We may have a confused BIOS,
+* or the user may have incorrectly supplied it via memmap=exactmap. If
+* we really are running on top non-RAM, we will crash later anyways.
+*/
+   if (!e820_all_mapped(code_resource.start, __pa(__brk_limit), E820_RAM)) 
{
+   pr_warn(".text .data .bss are not marked as E820_RAM!\n");
+
+   e820_add_region(code_resource.start,
+   __pa(__brk_limit) - code_resource.start + 1,
+   E820_RAM);
+   }
+
trim_bios_range();
 #ifdef CONFIG_X86_32
if (ppro_with_ram_bug()) {
-- 
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 V5 0/6] x86: Create direct mappings for E820_RAM only

[Jacob Shin]

This is the 5th revision of the patchset, which aims to create direct
mappings only for E820_RAM memory ranges. The problem description and
justification can be found in patch 4/6.

Previous discussion history can be found in the following threads:

* https://lkml.org/lkml/2012/8/24/474
* https://lkml.org/lkml/2012/8/22/680
* https://lkml.org/lkml/2012/8/13/512
* https://lkml.org/lkml/2012/8/9/536
* https://lkml.org/lkml/2011/10/20/323

Jacob Shin (4):
  x86/mm: find_early_table_space based on memory ranges that are being
mapped
  x86: Only direct map addresses that are marked as E820_RAM
  x86: Fixup code testing if a pfn is direct mapped
  x86: if kernel .text .data .bss are not marked as E820_RAM, complain
and fix

Yinghai Lu (2):
  x86, mm: Add page_size_mask()
  x86, mm: Split out split_mem_range

 arch/x86/include/asm/page_types.h |9 +++
 arch/x86/include/asm/pgtable.h|1 +
 arch/x86/kernel/cpu/amd.c |6 +-
 arch/x86/kernel/setup.c   |  115 ++
 arch/x86/mm/init.c|  162 -
 arch/x86/mm/init_64.c |6 +-
 arch/x86/platform/efi/efi.c   |8 +-
 7 files changed, 207 insertions(+), 100 deletions(-)

-- 
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 2/2] [2/2] extcon: optimising the check_mutually_exclusive function

[anish kumar]

From: anish kumar 

Rather than re-inventing the wheel we can use the hamming function
to calculate the number of bits set to check for violation of
exclusivity.

Signed-off-by: anish kumar 
---
 drivers/extcon/extcon-class.c |   14 +-
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index e09a6c3..06df95a 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -89,17 +89,13 @@ static int check_mutually_exclusive(struct extcon_dev 
*edev, u32 new_state)
return 0;
 
for (i = 0; edev->mutually_exclusive[i]; i++) {
-   int count = 0, j;
+   int weight;
u32 correspondants = new_state & edev->mutually_exclusive[i];
-   u32 exp = 1;
-
-   for (j = 0; j < 32; j++) {
-   if (exp & correspondants)
-   count++;
-   if (count > 1)
-   return i + 1;
-   exp <<= 1;
-   }
+
+   /* calculate the total number of bits set */
+   weight = hweight32(correspondants);
+   if (weight > 1)
+   return i + 1;
}
 
return 0;
-- 
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 5/6] x86: Fixup code testing if a pfn is direct mapped

[Jacob Shin]

Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.

Signed-off-by: Jacob Shin 
---
 arch/x86/kernel/cpu/amd.c   |6 +-
 arch/x86/platform/efi/efi.c |8 
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9d92e19..554ccfc 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -677,11 +677,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 */
if (!rdmsrl_safe(MSR_K8_TSEG_ADDR, )) {
printk(KERN_DEBUG "tseg: %010llx\n", tseg);
-   if ((tseg>>PMD_SHIFT) <
-   (max_low_pfn_mapped>>(PMD_SHIFT-PAGE_SHIFT)) ||
-   ((tseg>>PMD_SHIFT) <
-   (max_pfn_mapped>>(PMD_SHIFT-PAGE_SHIFT)) &&
-   (tseg>>PMD_SHIFT) >= (1ULL<<(32 - PMD_SHIFT
+   if (pfn_is_mapped(tseg))
set_memory_4k((unsigned long)__va(tseg), 1);
}
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 92660eda..f1facde 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -776,7 +776,7 @@ void __init efi_enter_virtual_mode(void)
efi_memory_desc_t *md, *prev_md = NULL;
efi_status_t status;
unsigned long size;
-   u64 end, systab, addr, npages, end_pfn;
+   u64 end, systab, addr, npages, start_pfn, end_pfn;
void *p, *va, *new_memmap = NULL;
int count = 0;
 
@@ -827,10 +827,10 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
 
+   start_pfn = PFN_DOWN(md->phys_addr);
end_pfn = PFN_UP(end);
-   if (end_pfn <= max_low_pfn_mapped
-   || (end_pfn > (1UL << (32 - PAGE_SHIFT))
-   && end_pfn <= max_pfn_mapped))
+
+   if (pfn_range_is_mapped(start_pfn, end_pfn))
va = __va(md->phys_addr);
else
va = efi_ioremap(md->phys_addr, size, md->type);
-- 
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 1/2] [1/2]extcon: standard cable names definition and declaration changed

[anish kumar]

From: anish kumar 

With this change now individual drivers can use standard cable
names as below:
static const char *arizona_cable[] = {
extcon_cable_name[EXTCON_USB],
extcon_cable_name[EXTCON_USB_HOST],
"CUSTOM_CABLE"
NULL,
}

Signed-off-by: anish kumar 
---
 drivers/extcon/extcon-class.c |4 +---
 include/linux/extcon.h|2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 481cfa0..e09a6c3 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -41,7 +41,7 @@
  * every single port-type of the following cable names. Please choose cable
  * names that are actually used in your extcon device.
  */
-const char *extcon_cable_name[] = {
+const char extcon_cable_name[][CABLE_NAME_MAX + 1] = {
[EXTCON_USB]= "USB",
[EXTCON_USB_HOST]   = "USB-Host",
[EXTCON_TA] = "TA",
@@ -62,8 +62,6 @@ const char *extcon_cable_name[] = {
[EXTCON_VIDEO_IN]   = "Video-in",
[EXTCON_VIDEO_OUT]  = "Video-out",
[EXTCON_MECHANICAL] = "Mechanical",
-
-   NULL,
 };
 
 static struct class *extcon_class;
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index cdd4014..96b5450 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -68,7 +68,7 @@ enum extcon_cable_name {
EXTCON_VIDEO_OUT,
EXTCON_MECHANICAL,
 };
-extern const char *extcon_cable_name[];
+extern const char extcon_cable_name[][CABLE_NAME_MAX + 1];
 
 struct extcon_cable;
 
-- 
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 4/6] x86: Only direct map addresses that are marked as E820_RAM

[Jacob Shin]

Currently direct mappings are created for [ 0 to max_low_pfn<
---
 arch/x86/include/asm/page_types.h |9 
 arch/x86/kernel/setup.c   |  100 +++--
 arch/x86/mm/init.c|2 +
 arch/x86/mm/init_64.c |6 +--
 4 files changed, 99 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index e21fdd1..409047a 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 /* PAGE_SHIFT determines the page size */
 #define PAGE_SHIFT 12
@@ -40,12 +41,20 @@
 #endif /* CONFIG_X86_64 */
 
 #ifndef __ASSEMBLY__
+#include 
 
 extern int devmem_is_allowed(unsigned long pagenr);
 
 extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;
 
+extern struct range pfn_mapped[E820_X_MAX];
+extern int nr_pfn_mapped;
+
+extern void add_pfn_range_mapped(unsigned long start_pfn, unsigned long 
end_pfn);
+extern bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long 
end_pfn);
+extern bool pfn_is_mapped(unsigned long pfn);
+
 static inline phys_addr_t get_max_mapped(void)
 {
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d6e8c03..a2e392e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -115,13 +115,47 @@
 #include 
 
 /*
- * end_pfn only includes RAM, while max_pfn_mapped includes all e820 entries.
- * The direct mapping extends to max_pfn_mapped, so that we can directly access
- * apertures, ACPI and other tables without having to play with fixmaps.
+ * max_low_pfn_mapped: highest direct mapped pfn under 4GB
+ * max_pfn_mapped: highest direct mapped pfn over 4GB
+ *
+ * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
+ * represented by pfn_mapped
  */
 unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;
 
+struct range pfn_mapped[E820_X_MAX];
+int nr_pfn_mapped;
+
+void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
+{
+   nr_pfn_mapped = add_range_with_merge(pfn_mapped, E820_X_MAX,
+nr_pfn_mapped, start_pfn, end_pfn);
+   nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
+
+   max_pfn_mapped = max(max_pfn_mapped, end_pfn);
+
+   if (end_pfn <= (1UL << (32 - PAGE_SHIFT)))
+   max_low_pfn_mapped = max(max_low_pfn_mapped, end_pfn);
+}
+
+bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
+{
+   int i;
+
+   for (i = 0; i < nr_pfn_mapped; i++)
+   if ((start_pfn >= pfn_mapped[i].start) &&
+   (end_pfn <= pfn_mapped[i].end))
+   return true;
+
+   return false;
+}
+
+bool pfn_is_mapped(unsigned long pfn)
+{
+   return pfn_range_is_mapped(pfn, pfn + 1);
+}
+
 #ifdef CONFIG_DMI
 RESERVE_BRK(dmi_alloc, 65536);
 #endif
@@ -296,6 +330,54 @@ static void __init cleanup_highmap(void)
 }
 #endif
 
+/*
+ * Iterate through E820 memory map and create direct mappings for only E820_RAM
+ * regions. We cannot simply create direct mappings for all pfns from
+ * [0 to max_low_pfn) and [4GB to max_pfn) because of possible memory holes in
+ * high addresses that cannot be marked as UC by fixed/variable range MTRRs.
+ * Depending on the alignment of E820 ranges, this may possibly result in using
+ * smaller size (i.e. 4K instead of 2M or 1G) page tables.
+ */
+static void __init init_direct_mapping(void)
+{
+   int i;
+
+   /* the ISA range is always mapped regardless of memory holes */
+   init_memory_mapping(0, ISA_END_ADDRESS);
+
+   for (i = 0; i < e820.nr_map; i++) {
+   struct e820entry *ei = [i];
+   u64 start = ei->addr;
+   u64 end = ei->addr + ei->size;
+
+   /* we only map E820_RAM */
+   if (ei->type != E820_RAM)
+   continue;
+
+   if (end <= ISA_END_ADDRESS)
+   continue;
+
+   if (start < ISA_END_ADDRESS)
+   start = ISA_END_ADDRESS;
+#ifdef CONFIG_X86_32
+   /* on 32 bit, we only map up to max_low_pfn */
+   if ((start >> PAGE_SHIFT) >= max_low_pfn)
+   continue;
+
+   if ((end >> PAGE_SHIFT) > max_low_pfn)
+   end = max_low_pfn << PAGE_SHIFT;
+#endif
+   init_memory_mapping(start, end);
+   }
+
+#ifdef CONFIG_X86_64
+   if (max_pfn > max_low_pfn) {
+   /* can we preseve max_low_pfn ?*/
+   max_low_pfn = max_pfn;
+   }
+#endif
+}
+
 static void __init reserve_brk(void)
 {
if (_brk_end > _brk_start)
@@ -914,18 +996,8 @@ void __init setup_arch(char **cmdline_p)
init_gbpages();
probe_page_size_mask();
 
-   /* max_pfn_mapped is updated here */
-   

[PATCH 3/6] x86/mm: find_early_table_space based on memory ranges that are being mapped

[Jacob Shin]

Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()

This patch also reportedly fixes suspend/resume issue reported in:

https://lkml.org/lkml/2012/8/11/83

Signed-off-by: Jacob Shin 
---
 arch/x86/mm/init.c |   62 +---
 1 file changed, 35 insertions(+), 27 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 41e615b..916b15b 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -37,40 +37,48 @@ struct map_range {
 
 static int page_size_mask;
 
-static void __init find_early_table_space(struct map_range *mr,
- unsigned long end)
+/*
+ * First calculate space needed for kernel direct mapping page tables to cover
+ * mr[0].start to mr[nr_range - 1].end, while accounting for possible 2M and 
1GB
+ * pages. Then find enough contiguous space for those page tables.
+ */
+static void __init find_early_table_space(struct map_range *mr, int nr_range)
 {
-   unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
+   int i;
+   unsigned long puds = 0, pmds = 0, ptes = 0, tables;
+   unsigned long start = 0, good_end;
phys_addr_t base;
 
-   puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
-   tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
-
-   if (page_size_mask & (1 << PG_LEVEL_1G)) {
-   unsigned long extra;
+   for (i = 0; i < nr_range; i++) {
+   unsigned long range, extra;
 
-   extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
-   pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
-   } else
-   pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+   range = mr[i].end - mr[i].start;
+   puds += (range + PUD_SIZE - 1) >> PUD_SHIFT;
 
-   tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
+   if (mr[i].page_size_mask & (1 << PG_LEVEL_1G)) {
+   extra = range - ((range >> PUD_SHIFT) << PUD_SHIFT);
+   pmds += (extra + PMD_SIZE - 1) >> PMD_SHIFT;
+   } else {
+   pmds += (range + PMD_SIZE - 1) >> PMD_SHIFT;
+   }
 
-   if (page_size_mask & (1 << PG_LEVEL_2M)) {
-   unsigned long extra;
-
-   extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
+   if (mr[i].page_size_mask & (1 << PG_LEVEL_2M)) {
+   extra = range - ((range >> PMD_SHIFT) << PMD_SHIFT);
 #ifdef CONFIG_X86_32
-   extra += PMD_SIZE;
+   extra += PMD_SIZE;
 #endif
-   /* The first 2/4M doesn't use large pages. */
-   if (mr->start < PMD_SIZE)
-   extra += mr->end - mr->start;
-
-   ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   } else
-   ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   /* The first 2/4M doesn't use large pages. */
+   if (mr[i].start < PMD_SIZE)
+   extra += range;
+
+   ptes += (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   } else {
+   ptes += (range + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   }
+   }
 
+   tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+   tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
 
 #ifdef CONFIG_X86_32
@@ -88,7 +96,7 @@ static void __init find_early_table_space(struct map_range 
*mr,
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
 
printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @ [mem 
%#010lx-%#010lx]\n",
-   end - 1, pgt_buf_start << PAGE_SHIFT,
+   mr[nr_range - 1].end - 1, pgt_buf_start << PAGE_SHIFT,
(pgt_buf_top << PAGE_SHIFT) - 1);
 }
 
@@ -273,7 +281,7 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
 * nodes are discovered.
 */
if (!after_bootmem)
-   find_early_table_space([0], end);
+   find_early_table_space(mr, nr_range);
 
for (i = 0; i < nr_range; i++)
ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
-- 
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 2/6] x86, mm: Split out split_mem_range

[Jacob Shin]

From: Yinghai Lu 

from init_memory_mapping, so make init_memory_mapping readable.

Suggested-by: Ingo Molnar 
Signed-off-by: Yinghai Lu 
---
 arch/x86/mm/init.c |   42 ++
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 838e9bc..41e615b 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -143,25 +143,13 @@ static int __meminit save_mr(struct map_range *mr, int 
nr_range,
return nr_range;
 }
 
-/*
- * Setup the direct mapping of the physical memory at PAGE_OFFSET.
- * This runs before bootmem is initialized and gets pages directly from
- * the physical memory. To access them they are temporarily mapped.
- */
-unsigned long __init_refok init_memory_mapping(unsigned long start,
-  unsigned long end)
+static int __meminit split_mem_range(struct map_range *mr, int nr_range,
+unsigned long start,
+unsigned long end)
 {
unsigned long start_pfn, end_pfn;
-   unsigned long ret = 0;
unsigned long pos;
-   struct map_range mr[NR_RANGE_MR];
-   int nr_range, i;
-
-   printk(KERN_INFO "init_memory_mapping: [mem %#010lx-%#010lx]\n",
-  start, end - 1);
-
-   memset(mr, 0, sizeof(mr));
-   nr_range = 0;
+   int i;
 
/* head if not big page alignment ? */
start_pfn = start >> PAGE_SHIFT;
@@ -255,6 +243,28 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
(mr[i].page_size_mask & (1

[PATCH 1/6] x86, mm: Add page_size_mask()

[Jacob Shin]

From: Yinghai Lu 

detect if need to use 1G or 2M and store them in page_size_mask.

Only probe them one time.

Suggested-by: Ingo Molnar 
Signed-off-by: Yinghai Lu 
---
 arch/x86/include/asm/pgtable.h |1 +
 arch/x86/kernel/setup.c|1 +
 arch/x86/mm/init.c |   66 +++-
 3 files changed, 33 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..e47e4db 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -597,6 +597,7 @@ static inline int pgd_none(pgd_t pgd)
 #ifndef __ASSEMBLY__
 
 extern int direct_gbpages;
+void probe_page_size_mask(void);
 
 /* local pte updates need not use xchg for locking */
 static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..d6e8c03 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -912,6 +912,7 @@ void __init setup_arch(char **cmdline_p)
setup_real_mode();
 
init_gbpages();
+   probe_page_size_mask();
 
/* max_pfn_mapped is updated here */
max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<> PUD_SHIFT;
tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
 
-   if (use_gbpages) {
+   if (page_size_mask & (1 << PG_LEVEL_1G)) {
unsigned long extra;
 
extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
@@ -54,7 +56,7 @@ static void __init find_early_table_space(struct map_range 
*mr, unsigned long en
 
tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
 
-   if (use_pse) {
+   if (page_size_mask & (1 << PG_LEVEL_2M)) {
unsigned long extra;
 
extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
@@ -90,6 +92,30 @@ static void __init find_early_table_space(struct map_range 
*mr, unsigned long en
(pgt_buf_top << PAGE_SHIFT) - 1);
 }
 
+void probe_page_size_mask(void)
+{
+#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_KMEMCHECK)
+   /*
+* For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
+* This will simplify cpa(), which otherwise needs to support splitting
+* large pages into small in interrupt context, etc.
+*/
+   if (direct_gbpages)
+   page_size_mask |= 1 << PG_LEVEL_1G;
+   if (cpu_has_pse)
+   page_size_mask |= 1 << PG_LEVEL_2M;
+#endif
+
+   /* Enable PSE if available */
+   if (cpu_has_pse)
+   set_in_cr4(X86_CR4_PSE);
+
+   /* Enable PGE if available */
+   if (cpu_has_pge) {
+   set_in_cr4(X86_CR4_PGE);
+   __supported_pte_mask |= _PAGE_GLOBAL;
+   }
+}
 void __init native_pagetable_reserve(u64 start, u64 end)
 {
memblock_reserve(start, end - start);
@@ -125,45 +151,15 @@ static int __meminit save_mr(struct map_range *mr, int 
nr_range,
 unsigned long __init_refok init_memory_mapping(unsigned long start,
   unsigned long end)
 {
-   unsigned long page_size_mask = 0;
unsigned long start_pfn, end_pfn;
unsigned long ret = 0;
unsigned long pos;
-
struct map_range mr[NR_RANGE_MR];
int nr_range, i;
-   int use_pse, use_gbpages;
 
printk(KERN_INFO "init_memory_mapping: [mem %#010lx-%#010lx]\n",
   start, end - 1);
 
-#if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KMEMCHECK)
-   /*
-* For CONFIG_DEBUG_PAGEALLOC, identity mapping will use small pages.
-* This will simplify cpa(), which otherwise needs to support splitting
-* large pages into small in interrupt context, etc.
-*/
-   use_pse = use_gbpages = 0;
-#else
-   use_pse = cpu_has_pse;
-   use_gbpages = direct_gbpages;
-#endif
-
-   /* Enable PSE if available */
-   if (cpu_has_pse)
-   set_in_cr4(X86_CR4_PSE);
-
-   /* Enable PGE if available */
-   if (cpu_has_pge) {
-   set_in_cr4(X86_CR4_PGE);
-   __supported_pte_mask |= _PAGE_GLOBAL;
-   }
-
-   if (use_gbpages)
-   page_size_mask |= 1 << PG_LEVEL_1G;
-   if (use_pse)
-   page_size_mask |= 1 << PG_LEVEL_2M;
-
memset(mr, 0, sizeof(mr));
nr_range = 0;
 
@@ -267,7 +263,7 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
 * nodes are discovered.
 */
if (!after_bootmem)
-   find_early_table_space([0], end, use_pse, use_gbpages);
+   find_early_table_space([0], end);
 
for (i = 0; i < nr_range; i++)
ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
-- 
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  

Re: "netpoll: re-enable irq in poll_napi()" breaks boot with netconsole

[David Miller]

From: Marcin Slusarz 
Date: Wed, 29 Aug 2012 20:53:29 +0200

> Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 
> did.
> I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d "netpoll:
> re-enable irq in poll_napi()" and reverting it on top of current Linus' tree
> restores proper behaviour (disabling netconsole does this too).
> "Not booting" manifests as immediate hang after network card enabling.

Fix is already pending, thanks:

http://patchwork.ozlabs.org/patch/179954/
--
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.6-rc3] wlcore: Declare MODULE_FIRMWARE usage

[Luciano Coelho]

On Wed, 2012-08-29 at 11:13 -0600, Tim Gardner wrote:
> On 08/29/2012 11:01 AM, Luciano Coelho wrote:
> > On Wed, 2012-08-29 at 08:48 -0600, Tim Gardner wrote:
> >> Cc: Luciano Coelho 
> >> Cc: "John W. Linville" 
> >> Cc: Eliad Peller 
> >> Cc: Arik Nemtsov 
> >> Cc: Eyal Shapira 
> >> Cc: linux-wirel...@vger.kernel.org
> >> Cc: net...@vger.kernel.org
> >> Signed-off-by: Tim Gardner 
> >> ---
> > 
> > Please add a proper commit message.  And there's no need to put all
> > these people in Cc: in the commit log.  CC'ing when sending the patch is
> > enough (even though for such small patch, the linux-wireless mailing
> > list and myself is enough).
> > 
> > --
> > Luca.
> > 
> 
> What more would you like covered in the commit message that isn't
> obvious from the subject?

It's obvious from the subject, indeed.  But commits with no descriptions
are ugly.  Add something, for example a small "why" would be nice.


> The Cc list comes from scripts/get_maintainers.pl as suggested by
> Documentation/SubmittingPatches: "5) Select e-mail destination."

Yeah, that's correct, but it doesn't mean you should put them as Cc:
tags in the commit log.  CCing when *sending* the email only is enough.
Most people won't really care for the entire lifetime of this patch.
And, come on, the Cc tags take more space than the actual patch.

--
Luca.

--
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/

"netpoll: re-enable irq in poll_napi()" breaks boot with netconsole

[Marcin Slusarz]

Hi

Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 did.
I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d "netpoll:
re-enable irq in poll_napi()" and reverting it on top of current Linus' tree
restores proper behaviour (disabling netconsole does this too).
"Not booting" manifests as immediate hang after network card enabling.

Cheers,
Marcin
--
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: Logitech USB headset not working in 3.6-rc3

[Bruno Wolff III]

On Wed, Aug 29, 2012 at 13:22:54 -0400,
  Josh Boyer  wrote:

On Wed, Aug 29, 2012 at 01:07:53PM -0400, Josh Boyer wrote:

> Right. New patch attached.

I'll try and get another kernel built with this later today.  I'm at
Plumbers so it might have to wait a bit.


OK, I got impatient with myself and got the kernel building sooner than
I said.  Bruno, you can find the kernel here when the build finishes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4434883

Please test and let us know.


I tested 3.6.0-0.rc3.git2.1.3.fc18.x86_64 on my machine at work and sound 
through the headset is working. I'll test my i686 machines at home tonight.

--
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 8/9 V3] workqueue: single pass rebind_workers

[Tejun Heo]

Hello, Lai.

On Thu, Aug 30, 2012 at 12:51:59AM +0800, Lai Jiangshan wrote:
> busy_worker_rebind_fn() can't return until all idle workers are rebound,
> the code of busy_worker_rebind_fn() ensure this.
> 
> So we can change the order of the code of rebind_workers(),
> and make it is a single pass to do the rebind_workers().
> 
> It makes the code much clean and better readability.

But, yeah, I do like this approach better.  Would it be possible to do
this without overloading manager_mutex?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i2c-eg20t: regression since i2c_add_numbered_adapter change

[Jean Delvare]

Hi guys,

Sorry for joining the discussion a little late, I was on vacation.

On Thu, 23 Aug 2012 16:28:52 +0800, Feng Tang wrote:
> On Wed, 22 Aug 2012 11:17:51 +0200
> Alexander Stein  wrote:
> > Am Mittwoch, 22. August 2012, 16:04:39 schrieb Feng Tang:
> > > > Why use a fixed one? Give the driver (and maybe every i2c bus driver) a 
> > > > parameter which sets the base bus number it should use.
> > > > E.g. i2c-eg20t.base-bus-num=2 so it will register the bus numbers 
> > > > starting from 2. If this parameter is unset. It would use the first 
> > > > free one, thus simply using i2c_add_adapter.

Looks like what media and sound drivers are/were doing to assign fixed
numbers to their devices. But my understanding is that this is a legacy
thing and nobody should need to use that any longer. Adding this to all
or even some i2c bus drivers looks like the wrong example to follow. If
your system has more than one device supported by the driver, it
doesn't even reliably guarantee fixed I2C bus numbers (especially if
some can be hot-plugged.)

> > > The reason we need a fixed number is it is easier for platform code
> > > which needs to register dozens of i2c devices to different controllers
> > > with i2c_register_board_info, and they need provide a bus number for
> > > each i2c device, this _binding_ info is not detectable but have to
> > > be fixed.

Whenever you call i2c_register_board_info(), every I2C bus number
referenced in the I2C device list passed as a parameter is reserved for
static I2C bus numbers, dynamic I2C bus numbers will never overlap.

So in the quoted example, if i2c-isch is able to dynamically pick I2C
bus number 0 while i2c-eg20t want it statically, it means that either
no device was declared on bus 0 with i2c_register_board_info(), or
i2c_register_board_info() was called too late in the game.

Note that there was an assumption at the time the code was written,
that there was no need or reason to reserve a static I2C bus number if
no slave device was declared on said I2C bus. I never much liked it but
it never caused problems so far. This means that either:
* you call i2c_register_board_info() to register your slave I2C devices
  and all the affected I2C bus drivers call i2c_add_numbered_adapter();
  or
* you don't call i2c_register_board_info() and all I2C bus drivers call
  i2c_add_adapter().
You can't mix, i.e. if you don't register any slave device on a bus but
the bus driver still calls i2c_add_numbered_adapter(), it may fail.

If this is a problem now on some systems, it should be easy enough to
work around by adding a specific function to reserve an I2C bus number
for static allocation, even without declaring any slave device on it.
This function would be called at the same time
i2c_register_board_info() typically is.

> > Yes, I'm aware of that. With "Why use a fixed one?" I meant why hard-code 
> > it into the driver. I should be changeable.
> > Because this is/was not possible in general to use i2c_register_board_info, 
> > so we used an echo to /sys/bus/i2c/devices/i2c-0/new_device or 
> > /sys/bus/i2c/devices/i2c-1/new_device.

Please elaborate on "this is/was not possible in general to use
i2c_register_board_info." You are supposed to call it as part of your
platform setup, so if it is not possible for you, whatever the problem
is needs to be addressed.

> Yeah, our EG20T kernel used to use the same "echo 
> /sys/bus/i2c/devices/i2c-x/new_device"
> way, but we found out it is not convenient for:
> 1. needs extra user space script, why not make it just work in kernel after
> boot? We have several i2c devices like touchscreen/radio which we wants them
> just work without depending user space action.

It should indeed be handled all in kernel space, using
i2c_register_board_info().

> 2. The i2c bus number is not fixed, which make the user space script even
> harder, as that number depends whether we compile into kernel all the i2c
> controllers (eg20t and isch) and whether these driver are compiled as
> modules and their loading order.

You can always look-up the right I2C bus number based on its name,
assuming your driver properly names them. There is some code doing that
at:
http://www.lm-sensors.org/browser/i2c-tools/trunk/tools/i2cbusses.c#L297

Ideally this code should move to libi2c and/or i2cdetect should offer
an interface to it, so it can easily be called from custom tools and
scripts.

> Thus we come out with this fixed bus number registering.
> 
> As I said before, either your module parameter "base_bus_num" solution
> or my fixed bus number offset are ok to me. Will you cook a patch?

I think the real problem you have here is that your platform setup code
doesn't (or is not able to) allocate the bus IDs globally. It really
should. If you have an embedded system using both i2c-eg20t and
i2c-isch, the platform setup code should decide upfront who gets what
I2C bus IDs, otherwise it's impossible to declare slave devices on
these I2C buses. And these bus drivers 

Re: [PATCH 7/9 V3] workqueue: explicit way to wait for idles workers to finish

[Tejun Heo]

Hello,

On Thu, Aug 30, 2012 at 12:51:58AM +0800, Lai Jiangshan wrote:
> busy_worker_rebind_fn() can't return until all idle workers are rebound.
> This order is ensured by rebind_workers() currently.
> 
> We use mutex_lock(>pool->manager_mutex) to wait for all idle workers
> to be rebound. this is an explicit way and it will ease the pain of
> the rebind_workers().
> 
> The sleeping mutex_lock(>pool->manager_mutex) must be put in the top 
> of
> busy_worker_rebind_fn(), because this busy worker thread can sleep
> before the WORKER_REBIND is cleared, but can't sleep after
> the WORKER_REBIND cleared.

I really can't say I like this overloading of manager_mutex.  CPU
up/down are actually behaving like the manager while it's holding the
manager_mutex at least.  I don't really think this
non-manager-role-manager-mutex usage is worthwhile whatever
simplification it makes to rebind path.  Rebind path being a bit ugly
/ complex is better than it muddling non-cpu-hotplug path further.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/9 V3] workqueue: add non_manager_role_manager_mutex_unlock()

[Tejun Heo]

On Thu, Aug 30, 2012 at 12:51:55AM +0800, Lai Jiangshan wrote:
> If hotplug code grabbed the manager_mutex and worker_thread try to create
> a worker, the manage_worker() will return false and worker_thread go to
> process work items. Now, on the CPU, all workers are processing work items,
> no idle_worker left/ready for managing. It breaks the concept of workqueue
> and it is bug.
> 
> So when this case happens, the last idle should not go to process work,
> it should go to sleep as usual and wait normal events. but it should
> also be notified by the event that hotplug code release the manager_mutex.
> 
> So we add non_manager_role_manager_mutex_unlock() to do this notify.

Hmmm... how about just running rebind_workers() from a work item?
That way, it would be guaranteed that there alwyas will be an extra
worker available on rebind completion.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7] net/bluetooth/rfcomm/core.c: fix error return code

[Marcel Holtmann]

Hi Julia,

> Initialize return variable before exiting on an error path.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> 
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  net/bluetooth/rfcomm/core.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Acked-by: Marcel Holtmann 

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/

Re: [PATCH 3/9 V3] workqueue: add POOL_MANAGING_WORKERS

[Tejun Heo]

Hello, Lai.

On Thu, Aug 30, 2012 at 12:51:54AM +0800, Lai Jiangshan wrote:
> When hotplug happens, the plug code will also grab the manager_mutex,
> it will break too_many_workers()'s assumption, and make too_many_workers()
> ugly(kick the timer wrongly, no found bug).
> 
> To avoid assumption-coruption, we add the original POOL_MANAGING_WORKERS back.

I don't think we're gaining anything with this and I'd like to confine
management state within the mutex only.  If too_many_workers() firing
spuriously while CPU up/down is in progress, just add a comment
explaining why it's a non-problem (actual worker management never
happens while cpu up/down holds manager positions).

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Michael S. Tsirkin]

On Wed, Aug 29, 2012 at 07:14:01PM +0200, Sasha Levin wrote:
> On 08/29/2012 05:38 PM, Michael S. Tsirkin wrote:
> > On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
> >> Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
> >> use indirect descriptors and allocate them using a simple
> >> kmalloc().
> >>
> >> This patch adds a cache which will allow indirect buffers under
> >> a configurable size to be allocated from that cache instead.
> >>
> >> Signed-off-by: Sasha Levin 
> > 
> > The API is ugly - how does driver know what to set?
> > Is this a typical request size? Then let's call it that.
> 
> We've discussed it during the RFC phase, the idea is that we don't know what
> would be a good number to use as threshold - which is why I'd like to keep it
> disabled as default until it gets more serious tests.
> 
> The driver doesn't know what to set, the plan was to make it a dynamic
> algorithms which would change it based on current load. Since I can't really 
> do
> testing which will provide the correct values for that, the decision was to do
> it this way as the first stage and modify it later.
> 
> > Also this is really per VQ, right?
> 
> Right, we keep it per-device at this stage to keep it simple.
> 
> > What is a good default for net? I guess max sg?
> 
> I think that it depends on the workload. I'd say we should keep the default 
> to 0
> (disabled) unless we can have a good way to adjust it to the load.

For *all* drivers?

Then it is mostly useless. No one has the time to tweak module
parameters in real life.

For virtio-net, 16+1 is not too much and ensures we always
use the cache.

If that works better than 0 I would say run with 17.


> >> ---
> >>
> >> Changes in v2:
> >>
> >>  - Free correctly indirect buffers.
> >>
> >>  drivers/block/virtio_blk.c  |  4 
> >>  drivers/char/hw_random/virtio-rng.c |  4 
> >>  drivers/char/virtio_console.c   |  4 
> >>  drivers/net/virtio_net.c|  4 
> >>  drivers/virtio/virtio_balloon.c |  4 
> >>  drivers/virtio/virtio_ring.c| 28 
> >>  include/linux/virtio.h  |  1 +
> >>  net/9p/trans_virtio.c   |  5 +
> >>  8 files changed, 50 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> >> index 13b8ae9..7f670af 100644
> >> --- a/drivers/block/virtio_blk.c
> >> +++ b/drivers/block/virtio_blk.c
> >> @@ -25,6 +25,9 @@ struct workqueue_struct *virtblk_wq;
> >>  static unsigned int indirect_thresh;
> >>  module_param(indirect_thresh, uint, S_IRUGO);
> >>  
> >> +static unsigned int indirect_alloc_thresh;
> >> +module_param(indirect_alloc_thresh, uint, S_IRUGO);
> >> +
> >>  struct virtio_blk
> >>  {
> >>struct virtio_device *vdev;
> >> @@ -739,6 +742,7 @@ static int __devinit virtblk_probe(struct 
> >> virtio_device *vdev)
> >>INIT_WORK(>config_work, virtblk_config_changed_work);
> >>vblk->config_enable = true;
> >>vdev->indirect_thresh = indirect_thresh;
> >> +  vdev->indirect_alloc_thresh = indirect_alloc_thresh;
> >>  
> >>err = init_vq(vblk);
> >>if (err)
> >> diff --git a/drivers/char/hw_random/virtio-rng.c 
> >> b/drivers/char/hw_random/virtio-rng.c
> >> index 02d8421..8475ece 100644
> >> --- a/drivers/char/hw_random/virtio-rng.c
> >> +++ b/drivers/char/hw_random/virtio-rng.c
> >> @@ -28,6 +28,9 @@
> >>  static unsigned int indirect_thresh;
> >>  module_param(indirect_thresh, uint, S_IRUGO);
> >>  
> >> +static unsigned int indirect_alloc_thresh;
> >> +module_param(indirect_alloc_thresh, uint, S_IRUGO);
> >> +
> >>  static struct virtqueue *vq;
> >>  static unsigned int data_avail;
> >>  static DECLARE_COMPLETION(have_data);
> >> @@ -97,6 +100,7 @@ static int probe_common(struct virtio_device *vdev)
> >>  
> >>/* We expect a single virtqueue. */
> >>vdev->indirect_thresh = indirect_thresh;
> >> +  vdev->indirect_alloc_thresh = indirect_alloc_thresh;
> >>vq = virtio_find_single_vq(vdev, random_recv_done, "input");
> >>if (IS_ERR(vq))
> >>return PTR_ERR(vq);
> >> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> >> index fc14e7f..c6f24a7 100644
> >> --- a/drivers/char/virtio_console.c
> >> +++ b/drivers/char/virtio_console.c
> >> @@ -42,6 +42,9 @@
> >>  static unsigned int indirect_thresh;
> >>  module_param(indirect_thresh, uint, S_IRUGO);
> >>  
> >> +static unsigned int indirect_alloc_thresh;
> >> +module_param(indirect_alloc_thresh, uint, S_IRUGO);
> >> +
> >>  /*
> >>   * This is a global struct for storing common data for all the devices
> >>   * this driver handles.
> >> @@ -1891,6 +1894,7 @@ static int __devinit virtcons_probe(struct 
> >> virtio_device *vdev)
> >>  >config.max_nr_ports) == 0)
> >>multiport = true;
> >>vdev->indirect_thresh = indirect_thresh;
> >> +  vdev->indirect_alloc_thresh = indirect_alloc_thresh;
> >>  
> >>err = 

Re: [PATCH 4/5] i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH

[Jean Delvare]

Hi James,

Quite a long Cc list for such a trivial patch...

On Thu,  9 Aug 2012 09:43:52 -0700, james.d.rals...@intel.com wrote:
> From: James Ralston 
> 
> This patch adds the SMBus Device IDs for the Intel Lynx Point-LP PCH. The 
> Device IDs are defined in drivers/i2c/busses/i2c-i801.c

I'm curious what the "LP" stands for. Low power?

> 
> Signed-off-by: James Ralston 
> ---
>  Documentation/i2c/busses/i2c-i801 |1 +
>  drivers/i2c/busses/Kconfig|1 +
>  drivers/i2c/busses/i2c-i801.c |3 +++
>  3 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/i2c/busses/i2c-i801 
> b/Documentation/i2c/busses/i2c-i801
> index 615142d..53207df 100644
> --- a/Documentation/i2c/busses/i2c-i801
> +++ b/Documentation/i2c/busses/i2c-i801
> @@ -21,6 +21,7 @@ Supported adapters:
>* Intel DH89xxCC (PCH)
>* Intel Panther Point (PCH)
>* Intel Lynx Point (PCH)
> +  * Intel Lynx Point_LP (PCH)

You spelled it "Lynx Point-LP" (with dash not underscore) in the patch
summary. Consistency in naming would be preferred. I'll use a dash
everywhere and apply your patch.

> Datasheets: Publicly available at the Intel website
>  
>  On Intel Patsburg and later chipsets, both the normal host SMBus controller
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 2e7530a..3500af7 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -104,6 +104,7 @@ config I2C_I801
>   DH89xxCC (PCH)
>   Panther Point (PCH)
>   Lynx Point (PCH)
> + Lynx Point_LP (PCH)
>  
> This driver can also be built as a module.  If so, the module
> will be called i2c-i801.
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 898dcf9..c467038 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -52,6 +52,7 @@
>DH89xxCC (PCH)0x2330 32 hard yes yes yes
>Panther Point (PCH)   0x1e22 32 hard yes yes yes
>Lynx Point (PCH)  0x8c22 32 hard yes yes yes
> +  Lynx Point_LP (PCH)   0x9c22 32 hard yes yes yes
>  
>Features supported by this driver:
>Software PEC no
> @@ -155,6 +156,7 @@
>  #define PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS   0x2330
>  #define PCI_DEVICE_ID_INTEL_5_3400_SERIES_SMBUS  0x3b30
>  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS  0x8c22
> +#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS   0x9c22
>  
>  struct i801_priv {
>   struct i2c_adapter adapter;
> @@ -771,6 +773,7 @@ static DEFINE_PCI_DEVICE_TABLE(i801_ids) = {
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS) },
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS) },
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS) 
> },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 
> PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS) },
>   { 0, }
>  };
>  


-- 
Jean Delvare
--
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/

[GIT PULL] (Was: uprobes: teach uprobes to clear MMF_HAS_UPROBES)

[Oleg Nesterov]

On 08/27, Oleg Nesterov wrote:
>
> Srikar, this is still waiting for your review ;)

I was informed that Srikar is travelling and can't review this seris.

So I think it doesn't make sense to delay the already acked patches,
the more testing the better ;) Yes, uprobe_munmap() looks strange,
we should either remove it or apply this series. But we can do this
later, and uprobes have other problems.

Ingo, please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes

Note: the patch from Sebastian wasn't acked by Srikar, but I hope
this cleanup is simple enough.

Oleg Nesterov (7):
  uprobes: Kill uprobes_state->count
  uprobes: Kill dup_mmap()->uprobe_mmap(), simplify uprobe_mmap/munmap
  uprobes: Change uprobe_mmap() to ignore the errors but check 
fatal_signal_pending()
  uprobes: Do not use -EEXIST in install_breakpoint() paths
  uprobes: Introduce MMF_HAS_UPROBES
  uprobes: Fold uprobe_reset_state() into uprobe_dup_mmap()
  uprobes: Remove "verify" argument from set_orig_insn()

Sebastian Andrzej Siewior (1):
  uprobes: Remove check for uprobe variable in handle_swbp()

Srikar Dronamraju (1):
  uprobes: Remove redundant lock_page/unlock_page

 include/linux/sched.h   |2 +
 include/linux/uprobes.h |   13 ++--
 kernel/events/uprobes.c |  159 +--
 kernel/fork.c   |6 +--
 4 files changed, 54 insertions(+), 126 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )

[Francesco Lavra]

Hi,

On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst
 wrote:

[Snip]

> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> new file mode 100644
> index 000..e0ceddd
> --- /dev/null
> +++ b/include/linux/dma-fence.h
> @@ -0,0 +1,124 @@
> +/*
> + * Fence mechanism for dma-buf to allow for asynchronous dma access
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License version 2 as
> published by
> + * the Free Software Foundation.
> + *
> + * 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, see .
> + */
> +
> +#ifndef __DMA_FENCE_H__
> +#define __DMA_FENCE_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 

Duplicated include.

Regards,
Francesco
--
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] block: Fix bad range check in bio_sector_offset

[Jeff Moyer]

"Martin K. Petersen"  writes:

>> "Jeff" == Jeff Moyer  writes:
>
>>> DM would occasionally end up splitting data integrity-enabled
>>> requests incorrectly. The culprit was a bad range check in
>>> bio_sector_offset.
>
> Jeff> The patch looks ok to me, but what is the user visible behavior
> Jeff> when this happens?
>
> We'd occasionally end up mapping a bad integrity scatterlist and the HBA
> would abort the I/O with a protection information error.

Thanks for the explanation, Martin!

Acked-by: Jeff Moyer 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] revert changes to zcache_do_preload()

[Seth Jennings]

Forget this whole thing, these reverts do _not_ fix the issue.

I wrote a test program to exercises cleancache and
determined that this problem has existed since the as far
back at v3.1 (basically the beginning).

No recent commit caused this.

Seth

--
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: HDD problem, software bug, bios bug, or hardware ?

[Adko Branil]

And one more thing i forgot - during kernel compilation i noticed this:

WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'



And when i compiled with "make CONFIG_DEBUG_SECTION_MISMATCH=y", somewhere at 
the end was:


WARNING: drivers/scsi/fcoe/libfcoe.o(.init.text+0x1f): Section mismatch in 
reference from the function libfcoe_init() to the function 
.exit.text:fcoe_transport_exit()
The function __init libfcoe_init() references
a function __exit fcoe_transport_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __exit annotation of
fcoe_transport_exit() so it may be used outside an exit section.



It should not be related with the crash during "make modules_install", as the 
default slackware kernel 3.2.27 also crashes during it, but it may be important 
for any other things, i don't know.


Thanks !
Adko.

--
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] regulator: tps6586x: register regulator even if no init data

[Stephen Warren]

On 08/29/12 08:01, Laxman Dewangan wrote:

Register all TPS6586x regulators even if there is no regulator
init data for platform i.e. without any user-supplied constraints.


I think this looks OK now, although I would like to test it, and check 
for any interactions etc. with the other TPS6586x patches, when I get 
back into the office next Tuesday.


--
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 -v12 02/15] resources: Add probe_resource()

[Yinghai Lu]

On Wed, Aug 29, 2012 at 8:57 AM, Yinghai Lu  wrote:
> also have another version for probe_resource, please check attached version 
> -v8.
>

sorry, v8 forget removing two lines.

please -v9 instead.

-v8: Linus said: allocation/return is not right, and -1 step tricks make it
not work as generic resource probe.
 So try to remove the needed_size tricks, and also use __adjust_resource
for probing instead.
-v9: remove two lines that is supposed to be removed after converting to use
__adjust_resource

Thanks

Yinghai


probe_resource_2.patch
Description: Binary data

Re: [PATCH v3] x86/uprobes: implement x86 specific arch_uprobe_*_step

[Oleg Nesterov]

On 08/22, Oleg Nesterov wrote:
>
> > Ehm. Is there anything I missed to do? Or are you speculating on
> > changes which will clash with these here?
>
> If we have task_set_blockstep(), then perhaps it mmakes sense to
> avoid user_enable_singlestep()/TIF_SINGLESTEP from the start.
> We will see.

But it is not clear when we will have task_set_blockstep.

So I am starting to think it would be better to apply your 1-2 and
change the code later. Still not correct, but better than nothing.



But. The more I think about the current code, the more I dislike it.
And I am starting to think we do not need yet another "weak arch*"
hook for single-stepping. Yes, it was me who suggested it, but this
is because I didn't want to complicate the merging of powerpc port.

However.

Ananth, Sebastian, what if we start with the patch below? Then
we can change arch/x86/kernel/uprobes.c to use the static
uprobe_*_step() helpers from the 2nd patch.

If we agree this code should be per-arch, then why do need other
hooks? This is just ugly, we already have arch_pre/post_xol.

The only problem is the pending powerpc patches, the change below
obviously breaks them. Were they already applied? If not, then
probably Ananth can do v6 on top of the patch below ;) The necessary
fixup is trivial.

What do you think?

Oleg.


--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -1440,10 +1440,8 @@ static void handle_swbp(struct pt_regs *
goto cleanup_ret;
 
utask->state = UTASK_SSTEP;
-   if (!pre_ssout(uprobe, regs, bp_vaddr)) {
-   user_enable_single_step(current);
+   if (!pre_ssout(uprobe, regs, bp_vaddr))
return;
-   }
 
 cleanup_ret:
if (utask) {
@@ -1480,7 +1478,6 @@ static void handle_singlestep(struct upr
put_uprobe(uprobe);
utask->active_uprobe = NULL;
utask->state = UTASK_RUNNING;
-   user_disable_single_step(current);
xol_free_insn_slot(current);
 
spin_lock_irq(>sighand->siglock);
--- x/arch/x86/kernel/uprobes.c
+++ x/arch/x86/kernel/uprobes.c
@@ -471,6 +471,7 @@ int arch_uprobe_pre_xol(struct arch_upro
regs->ip = current->utask->xol_vaddr;
pre_xol_rip_insn(auprobe, regs, autask);
 
+   user_enable_single_step(current);
return 0;
 }
 
@@ -596,6 +597,7 @@ int arch_uprobe_post_xol(struct arch_upr
if (auprobe->fixups & UPROBE_FIX_CALL)
result = adjust_ret_addr(regs->sp, correction);
 
+   user_disable_single_step(current);
return result;
 }
 
@@ -640,6 +642,7 @@ void arch_uprobe_abort_xol(struct arch_u
current->thread.trap_nr = utask->autask.saved_trap_nr;
handle_riprel_post_xol(auprobe, regs, NULL);
instruction_pointer_set(regs, utask->vaddr);
+   user_disable_single_step(current);
 }
 
 /*

--
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: [dm-devel] [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers

[Kent Overstreet]

On Wed, Aug 29, 2012 at 06:23:36PM +0100, Alasdair G Kergon wrote:
> On Wed, Aug 29, 2012 at 10:13:45AM -0700, Kent Overstreet wrote:
> > Only on allocation failure.
>  
> Which as you already said assumes wrapping together the other mempools in the
> submission path first...

Yes? I'm not sure what you're getting at.
--
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: tegra: moving phy driver into drivers directory

[Stephen Warren]

On 08/28/12 22:17, Venu Byravarasu wrote:

Stephen Warren wrote at Tuesday, August 28, 2012 7:37 PM:

On 08/28/2012 02:32 AM, Venu Byravarasu wrote:

In order to keep up with the USB driver files organization,
moving USB phy driver from mach-tegra to drivers/USB directory.

Signed-off-by: Venu Byravarasu 



diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-

tegra/devices.c


-struct tegra_ulpi_config tegra_ehci2_ulpi_phy_config = {
-   .reset_gpio = -1,
-   .clk = "cdev2",
-};
-
  struct tegra_ehci_platform_data tegra_ehci1_pdata = {
.operating_mode = TEGRA_USB_OTG,
.power_down_on_bus_suspend = 1,
@@ -450,7 +444,7 @@ struct tegra_ehci_platform_data tegra_ehci1_pdata

= {

  };

  struct tegra_ehci_platform_data tegra_ehci2_pdata = {
-   .phy_config = _ehci2_ulpi_phy_config,
+   .phy_config = NULL,


The PHY driver checks that field isn't NULL, and fails if it is:


struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int

instance,

 void __iomem *regs, void *config, enum tegra_usb_phy_mode

phy_mode)

{

...

 phy->config = config;
 phy->mode = phy_mode;

 if (!phy->config) {
 if (phy_is_ulpi(phy)) {
 pr_err("%s: ulpi phy configuration missing", __func__);
 err = -EINVAL;
 goto err0;


So, this change will completely break ULPI support, which currently
works fine. So, NAK.


My initial plan was to add support for phy interfaces one by one.
As part of that thought of UTMI only support at first and then add
ULPI and HSIC in next patches.
However as you were mentioning that it is not correct way, will
push ULPI & UTMI support at once in next patches.


But with the existing code, both ULPI and UTMI work. This patch breaks 
something that already works.



I also plan on deleting devices.[ch] in kernel 3.7, and moving the USB
platform data into board-dt-tegra20.c, since that's the only place it's
used right now. So, this patch would conflict with that rather badly. I
just posted the patches for that to the linux-tegra mailing list last
night. Do you have better proposals for that? Perhaps usb_phy.c should
set phy->config to _default in a similar fashion to how it works
for UTMI; that would remove some of the coupling between the changes.

BTW, in your response to Felipe, you said...


Thanks Felipe for your comments.
Created a patch to separate out phy related stuff to phy.h with you as a

reviewer.

Plz let me know your comments.


... where is that patch?


Plz see https://lkml.org/lkml/2012/8/28/58


Doesn't that link point at the patch I replied to?

--
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] tcp: Wrong timeout for SYN segments

[H.K. Jerry Chu]

Eric,

On Wed, Aug 29, 2012 at 1:51 AM, Eric Dumazet  wrote:
> On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:
>
>> IMHO 31secs seem a little short. Why not change it to 6 as well because 63
>> secs still beats 93secs with 3sec initRTO and 5 retries.
>>
>> Jerry
>>
>
> My rationale was that such increase were going to amplify SYN attacks
> impact by 20% (if we count number of useless SYNACK sent)

IMHO the main damage caused by SYN attack is DOS resulted from bogus
SYNs clogging the listener queue. I guess you've had numbers showing
that generating so many SYNACKs in response to bogus SYNs can be costly
too. But each bogus SYN that expires earlier will open up space sooner in the
listener queue for more bogus SYN so I'm not sure which one can induced
more damage.

Also if syn-cookie is enabled, it will dwarf the cost from
retransmitting SYN-ACK,
right?

>
> If the active side sends SYN packets for 180 seconds, do we really want
> to also send SYNACKS for additional 100 seconds ?

You have a good point. (I remember some folks in the past even question with
retransmitting SYN why SYN-ACK retransmit is necessary, other than for expedient
recovery purpose.)

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

>
> Sure, RFC numbers are what they are, but in practice, I doubt someone
> will really miss the extra SYNACK sent after ~32 seconds, since it would
> matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thanks,

Jerry

>
>
>
--
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: [dm-devel] [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers

[Alasdair G Kergon]

On Wed, Aug 29, 2012 at 10:13:45AM -0700, Kent Overstreet wrote:
> Only on allocation failure.
 
Which as you already said assumes wrapping together the other mempools in the
submission path first...

Alasdair

--
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: Logitech USB headset not working in 3.6-rc3

[Josh Boyer]

On Wed, Aug 29, 2012 at 01:07:53PM -0400, Josh Boyer wrote:
> > Right. New patch attached.
> 
> I'll try and get another kernel built with this later today.  I'm at
> Plumbers so it might have to wait a bit.

OK, I got impatient with myself and got the kernel building sooner than
I said.  Bruno, you can find the kernel here when the build finishes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4434883

Please test and let us know.

josh
--
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] HID: multitouch: Remove the redundant touch state

[Jiri Kosina]

On Wed, 29 Aug 2012, Benjamin Tissoires wrote:

> >> With the input_mt_sync_frame() function in place, there is no longer
> >> any need to keep the full touch state in the driver. This patch
> >> removes the slot state and replaces the lookup code with the input-mt
> >> equivalent. The initialization code is moved to mt_input_configured(),
> >> to make sure the full HID report has been seen.
> >>
> >> Signed-off-by: Henrik Rydberg 
> >> ---
> >> Hi Benjamin,
> >>
> >> Maybe this patch works better? It has received limited testing so far.
> >
> > What is the status of this patch please? Henrik, Benjamin?
> 
> Well, Henrik submitted a new release a few days ago (including this version).
> I just didn't found the time to test the whole thing on our different devices.
> It's now on the top of my TODO list.

Ah, I have missed the fact that this one is also part of Henrik's series, 
sorry for the noise.

I haven't unfortunately reviewed the series yet due to kernel summit & 
related events, but I'll get to it shortly.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] block: Fix bad range check in bio_sector_offset

[Jens Axboe]

On 2012-08-28 11:03, Martin K. Petersen wrote:
> 
> DM would occasionally end up splitting data integrity-enabled requests
> incorrectly. The culprit was a bad range check in bio_sector_offset.
> 
> Signed-off-by: Martin K. Petersen 
> Cc: 
> 
> diff --git a/fs/bio.c b/fs/bio.c
> index 9bfade8..b9a6744 100644
> --- a/fs/bio.c
> +++ b/fs/bio.c
> @@ -1552,8 +1552,8 @@ sector_t bio_sector_offset(struct bio *bio, unsigned 
> short index,
>   sector_sz = queue_logical_block_size(bio->bi_bdev->bd_disk->queue);
>   sectors = 0;
>  
> - if (index >= bio->bi_idx)
> - index = bio->bi_vcnt - 1;
> + if (index > bio->bi_vcnt)
> + return 0;
>  
>   __bio_for_each_segment(bv, bio, i, 0) {
>   if (i == index) {

Good catch, merged.

-- 
Jens Axboe

--
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/