Re: [PATCH v2] Staging: rtl8712: Removed unused return variable
On Thu, Apr 23, 2015 at 03:00:14PM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > This patch removes unused return variable in this file. > > Signed-off-by: Gnanachandran Dhanapal > --- your From: name and Signed-off-by: name is not matching. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: netcp: remove call to netif_carrier_(on/off) for MAC to Phy interface
On Friday 24 April 2015 12:47 AM, Murali Karicheri wrote: > Currently when interface type is MAC to Phy, netif_carrier_(on/off) > is called which is not needed as Phy lib already updates the carrier > status to net stack. This is needed only for other interface types > > Signed-off-by: Murali Karicheri > --- Acked-by: Mugunthan V N Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Did you get my donation message??
Did you get my donation message?? Best Regards, Maureen Hinckley Copyright ©2015• The Maureen Hinckley Foundation• All Rights Reserved -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RESEND PATCH 4/8] mfd: cros_ec: Use a zero-length array for command data
In general we can use kmalloc instead of kzalloc. Also some commands
do not need malloc at all. We could allocate on stack for known small
commands and for the keyboard case use the caller argument.
Gwendal.
On Mon, Apr 6, 2015 at 9:15 AM, Javier Martinez Canillas
wrote:
> Commit 1b84f2a4cd4a ("mfd: cros_ec: Use fixed size arrays to transfer
> data with the EC") modified the struct cros_ec_command fields to not
> use pointers for the input and output buffers and use fixed length
> arrays instead.
>
> This change was made because the cros_ec ioctl API uses that struct
> cros_ec_command to allow user-space to send commands to the EC and
> to get data from the EC. So using pointers made the API not 64-bit
> safe. Unfortunately this approach was not flexible enough for all
> the use-cases since there may be a need to send larger commands
> on newer versions of the EC command protocol.
>
> So to avoid to choose a constant length that it may be too big for
> most commands and thus wasting memory and CPU cycles on copy from
> and to user-space or having a size that is too small for some big
> commands, use a zero-length array that is both 64-bit safe and
> flexible. The same buffer is used for both output and input data
> so the maximum of these values should be used to allocate it.
>
> Suggested-by: Gwendal Grignou
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/i2c/busses/i2c-cros-ec-tunnel.c| 44 ++---
> drivers/input/keyboard/cros_ec_keyb.c | 27 --
> drivers/mfd/cros_ec.c | 26 +++--
> drivers/mfd/cros_ec_i2c.c | 4 +-
> drivers/mfd/cros_ec_spi.c | 2 +-
> drivers/platform/chrome/cros_ec_dev.c | 49 ++
> drivers/platform/chrome/cros_ec_lightbar.c | 151
> +++--
> drivers/platform/chrome/cros_ec_lpc.c | 8 +-
> drivers/platform/chrome/cros_ec_sysfs.c| 149 +---
> include/linux/mfd/cros_ec.h| 6 +-
> 10 files changed, 297 insertions(+), 169 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index fa8dedd8c3a2..4139ede8e6ed 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -183,7 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> int request_len;
> int response_len;
> int result;
> - struct cros_ec_command msg = { };
> + struct cros_ec_command *msg;
>
> request_len = ec_i2c_count_message(i2c_msgs, num);
> if (request_len < 0) {
> @@ -198,25 +198,39 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg i2c_msgs[],
> return response_len;
> }
>
> - result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num,
> bus_num);
> - if (result)
> - return result;
> + msg = kzalloc(sizeof(*msg) + max(request_len, response_len),
I2C commands are generally very small. We may want to pre-allocate a
small message and use kmalloc for larger one.
They usually come in pair: write 1 byte (the address), read/write 1
byte (the data).
Therefore a message that can accommodate 4 bytes for request and 4
bytes response would be plenty.
Also kmalloc is better than kzalloc, given we initialize the message
in ec_i2c_construct_message() bellow.
> + GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
>
> - msg.version = 0;
> - msg.command = EC_CMD_I2C_PASSTHRU;
> - msg.outsize = request_len;
> - msg.insize = response_len;
> + result = ec_i2c_construct_message(msg->data, i2c_msgs, num, bus_num);
> + if (result) {
> + dev_err(dev, "Error constructing EC i2c message %d\n",
> result);
> + goto exit;
> + }
>
> - result = cros_ec_cmd_xfer(bus->ec, );
> - if (result < 0)
> - return result;
> + msg->version = 0;
> + msg->command = EC_CMD_I2C_PASSTHRU;
> + msg->outsize = request_len;
> + msg->insize = response_len;
>
> - result = ec_i2c_parse_response(msg.indata, i2c_msgs, );
> - if (result < 0)
> - return result;
> + result = cros_ec_cmd_xfer(bus->ec, msg);
> + if (result < 0) {
> + dev_err(dev, "Error transferring EC i2c message %d\n",
> result);
> + goto exit;
> + }
> +
> + result = ec_i2c_parse_response(msg->data, i2c_msgs, );
> + if (result < 0) {
> + dev_err(dev, "Error parsing EC i2c message %d\n", result);
> + goto exit;
> + }
>
> /* Indicate success by saying how many messages were sent */
> - return num;
> + result = num;
> +exit:
> + kfree(msg);
> + return result;
> }
>
> static u32 ec_i2c_functionality(struct i2c_adapter *adap)
> diff --git
Re: [GIT PULL] kdbus for 4.1-rc1
On Thu, Apr 23, 2015 at 2:41 PM, Borislav Petkov wrote: > On Thu, Apr 23, 2015 at 11:22:39PM +0200, David Herrmann wrote: >> No it's not. O(256) equals O(1). > > Ok, you're right. Maybe O() was not the right thing to use when trying > to point out that iterating over 256 hash buckets and then following the > chain in each bucket per packet broadcast looks like a lot. > Heh. I guess you could call it an "expensive O(1)". While big-O notation is useful for describing algorithm scalability with respect to input size, it falls flat on its face when trying to articulate impact in measurable units. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Thunderbolt hotplug not working on MacMini7,1
On Thu, Apr 23, 2015 at 1:15 PM, Adam Goode wrote:
> On Thu, Apr 23, 2015 at 12:12 PM, Andreas Noever
> wrote:
>> On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode wrote:
>>> On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode wrote:
On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
wrote:
> Hi Adam,
>
> On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
> controller both use 0x1547 and are only differentiated by
> subvendor/subdevice.
>
> 0x156c is the 4 channel TB2 controller and was originally added by
> Matthew. Judging from his patch it looks like the subvendor/subdevice
> is set on his system:
> http://patchwork.ozlabs.org/patch/354626/
>
> But it also indicates that the bridges already use different ids. If
> that is the case then we can drop the subvendor/subdevice for 0x156c.
> Matthew can you confirm that on your system 0x156c is used only for
> the controller?
>
> Adam, could you check that suspend/resume works properly? Also your
> bugzilla report suggest that hotplug might now work without the
> driver. Could you try to revert the _OSI check (and disable the
> driver) and check whether everything "just works"?
>
In _OSI("Darwin") mode, suspend/resume doesn't work. It failed to come
back from suspend.
I have to rebuild the kernel and remove Darwin again, but I will test
suspend/resume in "Windows 2012" mode later.
From previous testing, hotplug doesn't automatically work in "Windows
2012" mode. It exhibits the standard no-driver behavior where devices
are not detected after boot. But even in "Windows 2012" mode I still
do get the 0x156c device, which I think used to be hidden if !Darwin.
More testing coming...
>>>
>>> I've booted into _OSI(Windows 2012) mode. I am not physically at the
>>> device right now, but here is the current dmesg with 1 thunderbolt
>>> device plugged in:
>>>
>>> [ 15.576766] thunderbolt :06:00.0: NHI initialized, starting
>>> thunderbolt
>>> [ 15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
>>> [ 15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
>>> [ 15.580008] thunderbolt :06:00.0: control channel created
>>> [ 15.581068] thunderbolt :06:00.0: control channel starting...
>>> [ 15.582122] thunderbolt :06:00.0: starting TX ring 0
>>> [ 15.583173] thunderbolt :06:00.0: enabling interrupt at
>>> register 0x38200 bit 0 (0x0 -> 0x1)
>>> [ 15.584228] thunderbolt :06:00.0: starting RX ring 0
>>> [ 15.585281] thunderbolt :06:00.0: enabling interrupt at
>>> register 0x38200 bit 12 (0x1 -> 0x1001)
>>> [ 15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
>>> (depth: 0, up port: 5)
>>> [ 15.587526] thunderbolt :06:00.0: old switch config:
>>> [ 15.588569] thunderbolt :06:00.0: Switch: 8086:156d (Revision:
>>> 0, TB Version: 2)
>>> [ 15.589581] thunderbolt :06:00.0: Max Port Number: 12
>>> [ 15.590557] thunderbolt :06:00.0: Config:
>>> [ 15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
>>> Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
>>> [ 15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
>>> [ 15.593530] thunderbolt :06:00.0: 0: unsupported switch device id
>>> 0x156d
>>> [ 15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
>>> [ 15.626919] thunderbolt :06:00.0: Port 0: 8086:156d (Revision:
>>> 0, TB Version: 1, Type: Port (0x1))
>>> [ 15.628028] thunderbolt :06:00.0: Max hop id (in/out): 7/7
>>> [ 15.629050] thunderbolt :06:00.0: Max counters: 8
>>> [ 15.630156] thunderbolt :06:00.0: NFC Credits: 0x70
>>> [ 15.631685] thunderbolt :06:00.0: Port 1: 8086:156d (Revision:
>>> 0, TB Version: 1, Type: Port (0x1))
>>> [ 15.632896] thunderbolt :06:00.0: Max hop id (in/out): 15/15
>>> [ 15.634000] thunderbolt :06:00.0: Max counters: 16
>>> [ 15.635001] thunderbolt :06:00.0: NFC Credits: 0x3c0
>>> [ 15.636582] thunderbolt :06:00.0: Port 2: 8086:156d (Revision:
>>> 0, TB Version: 1, Type: Port (0x1))
>>> [ 15.637737] thunderbolt :06:00.0: Max hop id (in/out): 15/15
>>> [ 15.638862] thunderbolt :06:00.0: Max counters: 16
>>> [ 15.639875] thunderbolt :06:00.0: NFC Credits: 0x3c0
>>> [ 15.641452] thunderbolt :06:00.0: Port 3: 8086:156d (Revision:
>>> 0, TB Version: 1, Type: Port (0x1))
>>> [ 15.642572] thunderbolt :06:00.0: Max hop id (in/out): 15/15
>>> [ 15.643702] thunderbolt :06:00.0: Max counters: 16
>>> [ 15.644683] thunderbolt :06:00.0: NFC Credits: 0x3c0
>>> [ 15.646250] thunderbolt :06:00.0: Port 4: 8086:156d (Revision:
>>> 0, TB Version: 1, Type: Port (0x1))
>>> [ 15.647285] thunderbolt :06:00.0: Max hop id (in/out): 15/15
>>> [ 15.648370]
linux-next: Tree for Apr 24
Hi all, Please do not add any v4.2 material to your linux-next included trees until after v4.1-rc1 is released. Changes since 20150423: The blackfin tree gained a conflict against Linus' tree. The kvm tree gained a conflict against the powerpc-merge-mpe tree. Non-merge commits (relative to Linus' tree): 1215 1486 files changed, 82889 insertions(+), 22643 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (27cf3a16b253 Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (6c5c2a01fcfd ARM: proc-arm94*.S: fix setup function) Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array index in OSS IRQ source initialization) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (2e826695d87c powerpc/mm: Fix build error with CONFIG_PPC_TRANSACTIONAL_MEM disabled) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (acc455cffa75 sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly) Merging net/master (e4b6c30375e8 ethernet: myri10ge: use arch_phys_wc_add()) Merging ipsec/master (092a29a40bab vti6: fix uninit when using x-netns) Merging sound-current/for-linus (7d1b6e293274 ALSA: hda - fix "num_steps = 0" error on ALC256) Merging pci-current/for-linus (9fbbda5c8e0a ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows) Merging wireless-drivers/master (69628cd0652a Merge tag 'iwlwifi-for-kalle-2015-03-30' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (bc465aa9d045 Linux 4.0-rc5) Merging tty.current/tty-linus (f22e6e847115 Linux 4.0-rc7) Merging usb.current/usb-linus (f22e6e847115 Linux 4.0-rc7) Merging usb-gadget-fixes/fixes (65582a7f4ce5 usb: isp1760: fix spin unlock in the error path of isp1760_udc_start) Merging usb-serial-fixes/usb-linus (39a8804455fb Linux 4.0) Merging staging.current/staging-linus (f22e6e847115 Linux 4.0-rc7) Merging char-misc.current/char-misc-linus (bc465aa9d045 Linux 4.0-rc5) Merging input-current/for-linus (48853389f206 Merge branch 'next' into for-linus) Merging crypto-current/master (3abafaf2192b crypto: arm - workaround for building with old binutils) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty ranges quirk for PA-Semi) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (ec76f4007079 vfio-pci: Add missing break to enable VFIO_PCI_ERR_IRQ_INDEX) Merging kselftest-fixes/fixes (67d8712dcc70 selftests: Fix build failures when invoked from kselftest target) Merging drm-intel-fixes/for-linux-next-fixes (39a8804455fb Linux 4.0) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic) Merging arc/for-next (d8f6ad85
[PATCH] tools/liblockdep: Fix linker error in case of cross compile.
If we try to cross compile liblockdep, even if we set the CROSS_COMPILE variable the linker error can occur because LD is not set with CROSS_COMPILE. This patch adds "LD" can be set automatically with CROSS_COMPILE variable so fixes linker error problem. Signed-off-by: Eunbong Song --- tools/lib/lockdep/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/tools/lib/lockdep/Makefile b/tools/lib/lockdep/Makefile index 0c356fb..18ffccf 100644 --- a/tools/lib/lockdep/Makefile +++ b/tools/lib/lockdep/Makefile @@ -14,9 +14,10 @@ define allow-override $(eval $(1) = $(2))) endef -# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix. +# Allow setting CC and AR and LD, or setting CROSS_COMPILE as a prefix. $(call allow-override,CC,$(CROSS_COMPILE)gcc) $(call allow-override,AR,$(CROSS_COMPILE)ar) +$(call allow-override,LD,$(CROSS_COMPILE)ld) INSTALL = install -- 1.7.0.1
Re: [PATCH v3 2/2] extcon-axp288: Add axp288 extcon driver support
Hi Ramakrishna, I'm sorry for late reply. On 04/09/2015 02:12 AM, Ramakrishna Pallala wrote: > This patch adds the extcon support for AXP288 PMIC which > has the BC1.2 charger detection capability. Additionally > it also adds the USB mux switching support b/w SOC and PMIC > based on GPIO control. > > Signed-off-by: Ramakrishna Pallala > --- > drivers/extcon/Kconfig |7 + > drivers/extcon/Makefile|1 + > drivers/extcon/extcon-axp288.c | 462 > > include/linux/mfd/axp20x.h |5 + > 4 files changed, 475 insertions(+) > create mode 100644 drivers/extcon/extcon-axp288.c > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig > index 6a1f7de..f6e8b2a 100644 > --- a/drivers/extcon/Kconfig > +++ b/drivers/extcon/Kconfig > @@ -28,6 +28,13 @@ config EXTCON_ARIZONA > with Wolfson Arizona devices. These are audio CODECs with > advanced audio accessory detection support. > > +config EXTCON_AXP288 > + tristate "X-Power AXP288 EXTCON support" > + depends on MFD_AXP20X && USB_PHY > + help > + Say Y here to enable support for USB peripheral detection > + and USB MUX switching by X-Power AXP288 PMIC. > + > config EXTCON_GPIO > tristate "GPIO extcon support" > depends on GPIOLIB > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile > index 0370b42..5429377 100644 > --- a/drivers/extcon/Makefile > +++ b/drivers/extcon/Makefile > @@ -5,6 +5,7 @@ > obj-$(CONFIG_EXTCON) += extcon-class.o > obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o > obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o > +obj-$(CONFIG_EXTCON_AXP288) += extcon-axp288.o > obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o > obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o > obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o > diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c > new file mode 100644 > index 000..363552c > --- /dev/null > +++ b/drivers/extcon/extcon-axp288.c > @@ -0,0 +1,462 @@ > +/* > + * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver > + * > + * Copyright (C) 2015 Intel Corporation > + * Author: Ramakrishna Pallala > + * > + * 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. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Power source status register */ > +#define PS_STAT_VBUS_TRIGGER BIT(0) > +#define PS_STAT_BAT_CHRG_DIR BIT(2) > +#define PS_STAT_VBUS_ABOVE_VHOLD BIT(3) > +#define PS_STAT_VBUS_VALID BIT(4) > +#define PS_STAT_VBUS_PRESENT BIT(5) > + > +/* BC module global register */ > +#define BC_GLOBAL_RUNBIT(0) > +#define BC_GLOBAL_DET_STAT BIT(2) > +#define BC_GLOBAL_DBP_TOUT BIT(3) > +#define BC_GLOBAL_VLGC_COM_SEL BIT(4) > +#define BC_GLOBAL_DCD_TOUT_MASK (BIT(6)|BIT(5)) > +#define BC_GLOBAL_DCD_TOUT_300MS 0 > +#define BC_GLOBAL_DCD_TOUT_100MS 1 > +#define BC_GLOBAL_DCD_TOUT_500MS 2 > +#define BC_GLOBAL_DCD_TOUT_900MS 3 > +#define BC_GLOBAL_DCD_DET_SELBIT(7) > + > +/* BC module vbus control and status register */ > +#define VBUS_CNTL_DPDM_PD_EN BIT(4) > +#define VBUS_CNTL_DPDM_FD_EN BIT(5) > +#define VBUS_CNTL_FIRST_PO_STAT BIT(6) > + > +/* BC USB status register */ > +#define USB_STAT_BUS_STAT_MASK (BIT(3)|BIT(2)|BIT(1)|BIT(0)) > +#define USB_STAT_BUS_STAT_SHIFT 0 > +#define USB_STAT_BUS_STAT_ATHD 0 > +#define USB_STAT_BUS_STAT_CONN 1 > +#define USB_STAT_BUS_STAT_SUSP 2 > +#define USB_STAT_BUS_STAT_CONF 3 > +#define USB_STAT_USB_SS_MODE BIT(4) > +#define USB_STAT_DEAD_BAT_DETBIT(6) > +#define USB_STAT_DBP_UNCFG BIT(7) > + > +/* BC detect status register */ > +#define DET_STAT_MASK(BIT(7)|BIT(6)|BIT(5)) > +#define DET_STAT_SHIFT 5 > +#define DET_STAT_SDP 1 > +#define DET_STAT_CDP 2 > +#define DET_STAT_DCP 3 > + > +/* IRQ enable-1 register */ > +#define PWRSRC_IRQ_CFG_MASK (BIT(4)|BIT(3)|BIT(2)) > + > +/* IRQ enable-6 register */ > +#define BC12_IRQ_CFG_MASKBIT(1) > + > +enum
[PATCH v4 2/2] thermal: hisilicon: add new hisilicon thermal sensor driver
From: kongxinwei
This patch adds the support for hisilicon thermal sensor, within
hisilicon SoC. there will register sensors for thermal framework
and use device tree to bind cooling device.
Signed-off-by: Leo Yan
Signed-off-by: kongxinwei
---
drivers/thermal/Kconfig| 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/hisi_thermal.c | 437 +
3 files changed, 446 insertions(+)
create mode 100644 drivers/thermal/hisi_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index af40db0..81aee01 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,6 +136,14 @@ config THERMAL_EMULATION
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
+config HISI_THERMAL
+ tristate "Hisilicon thermal driver"
+ depends on ARCH_HISI && CPU_THERMAL && OF
+ help
+ Enable this to plug hisilicon's thermal sensor driver into the Linux
+ thermal framework. cpufreq is used as the cooling device to throttle
+ CPUs when the passive trip is crossed.
+
config IMX_THERMAL
tristate "Temperature sensor driver for Freescale i.MX SoCs"
depends on CPU_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index fa0dc48..08ae7ac 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/
obj-$(CONFIG_INT340X_THERMAL) += int340x_thermal/
obj-$(CONFIG_ST_THERMAL) += st/
obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o
+obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
new file mode 100644
index 000..255c71b
--- /dev/null
+++ b/drivers/thermal/hisi_thermal.c
@@ -0,0 +1,437 @@
+/*
+ * Hisilicon thermal sensor driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Copyright (c) 2014-2015 Linaro Limited.
+ *
+ * Xinwei Kong
+ * Leo Yan
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define TEMP0_TH (0x4)
+#define TEMP0_RST_TH (0x8)
+#define TEMP0_CFG (0xC)
+#define TEMP0_EN (0x10)
+#define TEMP0_INT_EN (0x14)
+#define TEMP0_INT_CLR (0x18)
+#define TEMP0_RST_MSK (0x1C)
+#define TEMP0_VALUE(0x28)
+
+#define HISI_TEMP_BASE (-60)
+#define HISI_TEMP_RESET(10)
+
+#define HISI_MAX_SENSORS 4
+
+struct hisi_thermal_sensor {
+ struct hisi_thermal_data *thermal;
+ struct thermal_zone_device *tzd;
+ const struct thermal_trip *trip;
+
+ uint32_t id;
+ uint32_t thres_temp;
+ uint32_t reset_temp;
+};
+
+struct hisi_thermal_data {
+ struct mutex thermal_lock;
+ struct platform_device *pdev;
+ struct clk *clk;
+
+ int irq, irq_bind_sensor;
+ bool irq_enabled;
+
+ unsigned int sensors_num;
+ long sensor_temp[HISI_MAX_SENSORS];
+ struct hisi_thermal_sensor sensors[HISI_MAX_SENSORS];
+
+ void __iomem *regs;
+};
+
+/* in millicelsius */
+static inline int _step_to_temp(int step)
+{
+ /*
+* Every step equals (1 * 200) / 255 celsius, and finally
+* need convert to millicelsius.
+*/
+ return (HISI_TEMP_BASE + (step * 200 / 255)) * 1000;
+}
+
+static inline int _temp_to_step(int temp)
+{
+ return ((temp / 1000 - HISI_TEMP_BASE) * 255 / 200);
+}
+
+static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
+struct hisi_thermal_sensor *sensor)
+{
+ int val;
+
+ mutex_lock(>thermal_lock);
+
+ /* disable interrupt */
+ writel(0x0, data->regs + TEMP0_INT_EN);
+ writel(0x1, data->regs + TEMP0_INT_CLR);
+
+ /* disable module firstly */
+ writel(0x0, data->regs + TEMP0_EN);
+
+ /* select sensor id */
+ writel((sensor->id << 12), data->regs + TEMP0_CFG);
+
+ /* enable module */
+ writel(0x1, data->regs + TEMP0_EN);
+
+ usleep_range(3000, 5000);
+
+ val = readl(data->regs + TEMP0_VALUE);
+ val = _step_to_temp(val);
+
+ /* adjust for negative value */
[PATCH v4 0/2] 96boards: add thermal senor support to hikey board
From: kongxinwei The Linaro connect introduce 96boards series in Hong Kong,The HiKey board is the first board to be certified 96Boards Consumer Edition compatible. This board is based on the HiSilicon SoC. you can get more information from https://www.96boards.org. The hisilicon SoC contains thermal module, this thermal module has 4 sensors, - sensor 0: local sensor; - sensor 1: remote sensor for ACPU cluster 1; - sensor 2: remote sensor for ACPU cluster 2; - sensor 3: remote sensor for GPU; It can obtain this device temperature by operating this hardware. The new sensor driver satisfies thermal framework and to realize the ACPU ,GPU and so on to cool function. Changes v0->v1; * Delete this hi6220 dtsi. * Fix documentation and error checks. * Modify this driver which makes use of kernel to decide how to dynamically bind the interrupt to hottest sensor. * Delete "sensor-thres-temp" property and read thermal_zone trips points replace of it. * Delete "sensor-reset-temp" property and define the fixed value replace of it. Changes v1->v2; * change patch's position between binding document and driver file * clean up some regiser for enabling thermal sensor * use mutex lock to replace the spin lock Changes v2->v3; * delete sensor id property in binding document * fix sensor driver to satisfy sensor register after deleting sensor id property Changes v3->v4; * using "usleep_range" function instead of "msleep" function * delete code detail error kongxinwei (2): dt-bindings: Document the hi6220 thermal sensor bindings thermal: hisilicon: add new hisilicon thermal sensor driver .../bindings/thermal/hisilicon-thermal.txt | 23 ++ drivers/thermal/Kconfig| 8 + drivers/thermal/Makefile | 1 + drivers/thermal/hisi_thermal.c | 437 + 4 files changed, 469 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt create mode 100644 drivers/thermal/hisi_thermal.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue
On Thu, Apr 23, 2015 at 10:15 PM, Andy Lutomirski wrote: > AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET > with SS == 0 results in an invalid usermode state in which SS is > apparently equal to __USER_DS but causes #SS if used. > > Work around the issue by replacing NULL SS values with __KERNEL_DS > in __switch_to, thus ensuring that SYSRET never happens with SS set > to NULL. > > This was exposed by a recent vDSO cleanup. > > Fixes: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss > Signed-off-by: Andy Lutomirski > --- > > Tested only on Intel, which isn't very interesting. I'll tidy up > and send a test case, too, once Borislav confirms that it works. > > Please don't actually apply this until we're sure we understand the > scope of the issue. If this doesn't affect SYSRETQ, then we might > to fix it on before SYSRETL to avoid impacting 64-bit processes > at all. It works with Wine. Tested on an AMD Phenom II. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 1/2] dt-bindings: Document the hi6220 thermal sensor bindings
From: kongxinwei
This adds documentation of device tree bindings for the
thermal sensor controller of hi6220 SoC.
Signed-off-by: Leo Yan
Signed-off-by: kongxinwei
---
.../bindings/thermal/hisilicon-thermal.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
new file mode 100644
index 000..b2a349f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
@@ -0,0 +1,23 @@
+* Temperature Sensor on hisilicon SoCs
+
+** Required properties :
+
+- compatible: "hisilicon,tsensor".
+- reg: physical base address of thermal sensor and length of memory mapped
+ region.
+- interrupt: The interrupt number to the cpu. Defines the interrupt used
+ by SOCTHERM.
+- clock-names: Input clock name, should be 'thermal_clk'.
+- clocks: phandles for clock specified in "clock-names" property.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+
+ tsensor: tsensor@0,f7030700 {
+ compatible = "hisilicon,tsensor";
+ reg = <0x0 0xf7030700 0x0 0x1000>;
+ interrupts = <0 7 0x4>;
+ clocks = <_sys HI6220_TSENSOR_CLK>;
+ clock-names = "thermal_clk";
+ #thermal-sensor-cells = <1>;
+ }
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[uclinux-dist-devel] [GIT PULL] Blackfin fixes for v4.1
Hi Linus, please pull blackfin fixes for v4.1, PM, kgdb, debug mmr fix, add gpio softswitch, update defconfig and board files, and build fixes. The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76: Linux 4.0 (2015-04-12 15:12:50 -0700) are available in the git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git tags/blackfin-for-linus for you to fetch changes up to d91e14b3b9e1d8e1d552f4d6aff45551bbb410b1: eth: bf609 eth clock: add pclk clock for stmmac driver probe (2015-04-24 11:36:35 +0800) blackfin updates for Linux 4.1 Aaron Wu (1): pm: sometimes wake up from suspend to RAM would fail Andre Wolokita (1): debug-mmrs: Eliminate all traces of the USB_PHY_TEST MMR Chen Gang (1): blackfin: Wire up missing syscalls Rickard Strandqvist (2): arch: blackfin: kernel: setup.c: Cleaning up missing null-terminate in conjunction with strncpy arch: blackfin: kernel: kgdb: Remove unused function Scott Jiang (2): bf609: use new SND_BF6XX_PCM to choose audio pcm driver bf609: add resources for lcd nl8048 Sonic Zhang (5): bug[220] kgdb: change the smp cross core function entry bf609: add gpio soft switch platform data for mcp23017 i2c devices bf609: enable soft switch gpio driver by default bf609: add platform data for soft switch devices on the video extenders bf609: remove softswitch i2c configuration from adv7842 and adv7511 platform data Steven Miao (4): blackfin: defconfigs: cleanup unused CONFIG_MTD_CHAR, add MTD_SPI_NOR for BF537-STAMP blackfin: io: define __raw_readx/writex with bfin_readx/writex dma: fix build error after update to v3.19 eth: bf609 eth clock: add pclk clock for stmmac driver probe arch/blackfin/configs/BF518F-EZBRD_defconfig |1 - arch/blackfin/configs/BF527-TLL6527M_defconfig|1 - arch/blackfin/configs/BF533-EZKIT_defconfig |1 - arch/blackfin/configs/BF533-STAMP_defconfig |1 - arch/blackfin/configs/BF537-STAMP_defconfig |3 +- arch/blackfin/configs/BF538-EZKIT_defconfig |1 - arch/blackfin/configs/BF561-ACVILON_defconfig |1 - arch/blackfin/configs/BF561-EZKIT-SMP_defconfig |1 - arch/blackfin/configs/BF561-EZKIT_defconfig |1 - arch/blackfin/configs/BF609-EZKIT_defconfig |1 + arch/blackfin/configs/CM-BF527_defconfig |1 - arch/blackfin/configs/CM-BF533_defconfig |1 - arch/blackfin/configs/CM-BF537E_defconfig |1 - arch/blackfin/configs/CM-BF537U_defconfig |1 - arch/blackfin/configs/CM-BF548_defconfig |1 - arch/blackfin/configs/CM-BF561_defconfig |1 - arch/blackfin/configs/DNP5370_defconfig |1 - arch/blackfin/configs/IP0X_defconfig |1 - arch/blackfin/configs/PNAV-10_defconfig |1 - arch/blackfin/configs/SRV1_defconfig |1 - arch/blackfin/configs/TCM-BF518_defconfig |1 - arch/blackfin/configs/TCM-BF537_defconfig |1 - arch/blackfin/include/asm/io.h| 35 ++-- arch/blackfin/include/uapi/asm/unistd.h | 12 ++- arch/blackfin/kernel/debug-mmrs.c |1 - arch/blackfin/kernel/kgdb.c | 25 +- arch/blackfin/kernel/setup.c |2 +- arch/blackfin/mach-bf527/include/mach/cdefBF525.h |5 -- arch/blackfin/mach-bf527/include/mach/defBF525.h |4 - arch/blackfin/mach-bf548/include/mach/cdefBF542.h |4 - arch/blackfin/mach-bf548/include/mach/cdefBF547.h |4 - arch/blackfin/mach-bf548/include/mach/defBF542.h |3 - arch/blackfin/mach-bf548/include/mach/defBF547.h |3 - arch/blackfin/mach-bf609/boards/ezkit.c | 90 +++-- arch/blackfin/mach-bf609/clock.c |7 ++ arch/blackfin/mach-common/entry.S | 10 +++ arch/blackfin/mach-common/pm.c|2 + 37 files changed, 127 insertions(+), 104 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 v2 1/2] soc: qcom: Add device tree binding for SMEM
On Thu, Apr 23, 2015 at 1:01 PM, Jeffrey Hugo wrote: > On 4/11/2015 5:32 PM, Bjorn Andersson wrote: >> >> Add device tree binding documentation for the Qualcom Shared Memory >> manager. >> [..] > > For my information, is there any intention to support the relocatable > smem_region by looking it up at init time? It does not seem like it would > be possible to support that with this binding. > I haven't been able to grasp the purpose of making the smem addresses completely dynamic. As far as I can see there might be use cases where certain devices needs to move the smem region from the default area. But even so, it's not dynamically choosen so it's in essence static - so we can just encode it in the individual dts files. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/4] arm64: add livepatch support
On 2015/4/24 10:44, AKASHI Takahiro wrote: > This patchset enables livepatch support on arm64. > > Livepatch was merged in v4.0, and allows replacying a function dynamically > based on ftrace framework, but it also requires -mfentry option of gcc. > Currently arm64 gcc doesn't support it, but by adding a helper function to > ftrace, we will be able to support livepatch on arch's which don't support > this option. > This is not correct for the case that the prologue of the old and new function is different. Thanks, Li Bin > I submit this patchset as RFC since I'm not quite sure that I'm doing > in the right way, or we should definitely support -fentry instead. > > Please note that I tested the feature only with livepatch-sample, and > the code for DYNAMIC_TRACE_WITH_REGS is still rough-edged. > > To: Steven Rostedt > To: Ingo Molnar > To: Josh Poimboeuf > To: Seth Jennings > To: Jiri Kosina > To: Vojtech Pavlik > To: Catalin Marinas > To: Will Deacon > > AKASHI Takahiro (4): > ftrace: add a helper function for livepatch > livepatch: adjust a patched function's address > arm64: ftrace: add DYNAMIC_TRACE_WITH_REGS version > arm64: add livepatch support > > arch/arm64/Kconfig |4 ++ > arch/arm64/include/asm/ftrace.h|4 ++ > arch/arm64/include/asm/livepatch.h | 38 +++ > arch/arm64/kernel/Makefile |1 + > arch/arm64/kernel/entry-ftrace.S | 124 > > arch/arm64/kernel/ftrace.c | 24 ++- > arch/arm64/kernel/livepatch.c | 68 > arch/x86/include/asm/livepatch.h |5 ++ > include/linux/ftrace.h |2 + > include/linux/livepatch.h |2 + > kernel/livepatch/core.c| 16 +++-- > kernel/trace/ftrace.c | 26 > 12 files changed, 309 insertions(+), 5 deletions(-) > create mode 100644 arch/arm64/include/asm/livepatch.h > create mode 100644 arch/arm64/kernel/livepatch.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: loop block-mq conversion scalability issues
Hi Justin,
Thanks for the report.
On Thu, 23 Apr 2015 16:04:10 -0500
"Justin M. Forbes" wrote:
> The block-mq conversion for loop in 4.0 kernels is showing us an
> interesting scalability problem with live CDs (ro, squashfs). It was
> noticed when testing the Fedora beta that the more CPUs a liveCD image
> was given, the slower it would boot. A 4 core qemu instance or bare
> metal instance took more than twice as long to boot compared to a single
> CPU instance. After investigating, this came directly to the block-mq
> conversion, reverting these 4 patches will return performance. More
> details are available at
> https://bugzilla.redhat.com/show_bug.cgi?id=1210857
> I don't think that reverting the patches is the ideal solution so I am
> looking for other options. Since you know this code a bit better than I
> do I thought I would run it by you while I am looking as well.
I can understand the issue because the default @max_active for
alloc_workqueue() is quite big(512), which may cause too much
context switchs, then loop I/O performance gets decreased.
Actually I have written the kernel dio/aio based patch for decreasing
both CPU and memory utilization without sacrificing I/O performance,
and I will try to improve and push the patch during this cycle and hope
it can be merged(kernel/aio.c change is dropped, and only fs change is
needed on fs/direct-io.c).
But the following change should help for your case, could you test it?
---
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c6b3726..b1cb41d 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1831,7 +1831,7 @@ static int __init loop_init(void)
}
loop_wq = alloc_workqueue("kloopd",
- WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0);
+ WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 32);
if (!loop_wq) {
err = -ENOMEM;
goto misc_out;
Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] arm64: add livepatch support
On Fri, 24 Apr 2015 11:44:05 +0900 AKASHI Takahiro wrote: > This patchset enables livepatch support on arm64. > > Livepatch was merged in v4.0, and allows replacying a function dynamically > based on ftrace framework, but it also requires -mfentry option of gcc. > Currently arm64 gcc doesn't support it, but by adding a helper function to > ftrace, we will be able to support livepatch on arch's which don't support > this option. > > I submit this patchset as RFC since I'm not quite sure that I'm doing > in the right way, or we should definitely support -fentry instead. You need to be extremely careful about this. I don't know what arm does with mcount but on x86 without -fentry, it sets up the stack frame before calling mcount. That is, if mcount returns to a different function, it doesn't mean that the registers will match the parameters. I have to look at what arm64 does when compiled with -pg. Because, if it moves registers around before the mcount, you will have a disaster on your hands if it returns to a different function that moved the registers around differently. Also, you need to be careful about how link registers are handled. -- Steve > > Please note that I tested the feature only with livepatch-sample, and > the code for DYNAMIC_TRACE_WITH_REGS is still rough-edged. > > To: Steven Rostedt > To: Ingo Molnar > To: Josh Poimboeuf > To: Seth Jennings > To: Jiri Kosina > To: Vojtech Pavlik > To: Catalin Marinas > To: Will Deacon > > AKASHI Takahiro (4): > ftrace: add a helper function for livepatch > livepatch: adjust a patched function's address > arm64: ftrace: add DYNAMIC_TRACE_WITH_REGS version > arm64: add livepatch support > > arch/arm64/Kconfig |4 ++ > arch/arm64/include/asm/ftrace.h|4 ++ > arch/arm64/include/asm/livepatch.h | 38 +++ > arch/arm64/kernel/Makefile |1 + > arch/arm64/kernel/entry-ftrace.S | 124 > > arch/arm64/kernel/ftrace.c | 24 ++- > arch/arm64/kernel/livepatch.c | 68 > arch/x86/include/asm/livepatch.h |5 ++ > include/linux/ftrace.h |2 + > include/linux/livepatch.h |2 + > kernel/livepatch/core.c| 16 +++-- > kernel/trace/ftrace.c | 26 > 12 files changed, 309 insertions(+), 5 deletions(-) > create mode 100644 arch/arm64/include/asm/livepatch.h > create mode 100644 arch/arm64/kernel/livepatch.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/
[RFC 3/4] arm64: ftrace: add DYNAMIC_TRACE_WITH_REGS version
CONFIG_DYNAMIC_TRACE_WITH_REGS is a prerequisite for ftrace-based kprobes as well as livepatch. This patch adds ftrace_regs_caller(), which will pass pt_regs info to ftrace handlers, to enable this config. Signed-off-by: AKASHI Takahiro --- arch/arm64/Kconfig |1 + arch/arm64/include/asm/ftrace.h |4 ++ arch/arm64/kernel/entry-ftrace.S | 124 ++ arch/arm64/kernel/ftrace.c | 24 +++- 4 files changed, 152 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e973..c3678ed 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -54,6 +54,7 @@ config ARM64 select HAVE_DMA_ATTRS select HAVE_DMA_CONTIGUOUS select HAVE_DYNAMIC_FTRACE + select HAVE_DYNAMIC_FTRACE_WITH_REGS select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_TRACER diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h index c5534fa..5a14269 100644 --- a/arch/arm64/include/asm/ftrace.h +++ b/arch/arm64/include/asm/ftrace.h @@ -16,6 +16,10 @@ #define MCOUNT_ADDR((unsigned long)_mcount) #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE +#ifdef CONFIG_DYNAMIC_FTRACE +#define ARCH_SUPPORTS_FTRACE_OPS 1 +#endif + #ifndef __ASSEMBLY__ #include diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index 08cafc5..fed28eb 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -10,6 +10,7 @@ */ #include +#include #include #include @@ -86,6 +87,95 @@ add \reg, \reg, #8 .endm +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS +/* + * stack layout after mcount_save_regs in _mcount(): + * + * current sp/fp => 0:+-+ + * in _mcount()|pt_regs | + * | | + * | +-+ + * | | x29 | -> instrumented function's fp + * | +-+ + * | | x30 | -> _mcount()'s lr + * | +-+ (= instrumented function's pc) + * +S_FRAME_SIZE | | + * old sp => :+-+--- + * when instrumented | | + * function calls | ... | + * _mcount() | | + * | | + * instrumented => +xx:+-+ + * function's fp | x29 | -> parent's fp + * +-+ + * | x30 | -> instrumented function's lr (= parent's pc) + * +-+ + * | ... | + */ + .macro mcount_save_regs + sub sp, sp, #S_FRAME_SIZE + + stp x0, x1, [sp, #8 * 0] + stp x2, x3, [sp, #8 * 2] + stp x4, x5, [sp, #8 * 4] + stp x6, x7, [sp, #8 * 6] + stp x8, x9, [sp, #8 * 8] + stp x10, x11, [sp, #8 * 10] + stp x12, x13, [sp, #8 * 12] + stp x14, x15, [sp, #8 * 14] + stp x16, x17, [sp, #8 * 16] + stp x18, x19, [sp, #8 * 18] + stp x20, x21, [sp, #8 * 20] + stp x22, x23, [sp, #8 * 22] + stp x24, x25, [sp, #8 * 24] + stp x26, x27, [sp, #8 * 26] + stp x28, x29, [sp, #8 * 28] + + ldr x0, [x29, #8] + mcount_adjust_addr x0, x0 + str x0, [sp, #S_LR] + + add x0, sp, #S_FRAME_SIZE + str x0, [sp, #S_SP] + + mcount_adjust_addr x0, x30 + str x0, [sp, #S_PC] + + ldr x0, [sp, #8 * 0] + + mov x29, sp + .endm + + /* for instrumented function */ + .macro mcount_get_lr1 reg + ldr \reg, [x29, #8 * 29] + ldr \reg, [\reg, #8] + mcount_adjust_addr \reg, \reg + .endm + + .macro mcount_restore_rest_regs + ldp x0, x1, [sp, #8 * 0] + ldp x2, x3, [sp, #8 * 2] + ldp x4, x5, [sp, #8 * 4] + ldp x6, x7, [sp, #8 * 6] + ldp x8, x9, [sp, #8 * 8] + ldp x10, x11, [sp, #8 * 10] + ldp x12, x13, [sp, #8 * 12] + ldp x14, x15, [sp, #8 * 14] + ldp x16, x17, [sp, #8 * 16] + ldp x18, x19, [sp, #8 * 18] + ldp x20, x21, [sp, #8 * 20] + ldp x22, x23, [sp, #8 * 22] + ldp x24, x25, [sp, #8 * 24] + ldp x26, x27, [sp, #8 * 26] + ldp x28, x29, [sp, #8 * 28] + ldr x30, [sp, #S_LR] + add sp, sp, #S_FRAME_SIZE + + mcount_enter + .endm +#endif /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */ + #ifndef CONFIG_DYNAMIC_FTRACE /* * void _mcount(unsigned long return_address) @@ -156,6 +246,10 @@ ENTRY(ftrace_caller) mcount_get_pc0 x0 // function's pc mcount_get_lr x1 // function's lr + adrp x2, function_trace_op + add x2, x2, #:lo12:function_trace_op + ldr x2, [x2]// current ftrace_ops +
[RFC 4/4] arm64: add livepatch support
Signed-off-by: AKASHI Takahiro
---
arch/arm64/Kconfig |3 ++
arch/arm64/include/asm/livepatch.h | 38
arch/arm64/kernel/Makefile |1 +
arch/arm64/kernel/livepatch.c | 68
4 files changed, 110 insertions(+)
create mode 100644 arch/arm64/include/asm/livepatch.h
create mode 100644 arch/arm64/kernel/livepatch.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c3678ed..d4b5bac 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -61,6 +61,7 @@ config ARM64
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
+ select HAVE_LIVEPATCH
select HAVE_MEMBLOCK
select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
@@ -612,6 +613,8 @@ config SETEND_EMULATION
If unsure, say Y
endif
+source "kernel/livepatch/Kconfig"
+
endmenu
menu "Boot options"
diff --git a/arch/arm64/include/asm/livepatch.h
b/arch/arm64/include/asm/livepatch.h
new file mode 100644
index 000..590d139
--- /dev/null
+++ b/arch/arm64/include/asm/livepatch.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2015 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * 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.
+ */
+#ifndef __ASM_LIVEPATCH_H
+#define __ASM_LIVEPATCH_H
+
+#include
+#include
+
+#ifdef CONFIG_LIVEPATCH
+static inline int klp_check_compiler_support(void)
+{
+ return 0;
+}
+extern int klp_write_module_reloc(struct module *mod, unsigned long type,
+ unsigned long loc, unsigned long value);
+
+extern unsigned long ftrace_lookup_mcount(unsigned long addr);
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+ regs->regs[30] = ip;
+}
+
+static inline unsigned long klp_arch_lookup_mcount(unsigned long addr)
+{
+ return ftrace_lookup_mcount(addr);
+}
+#else
+#error Live patching support is disabled; check CONFIG_LIVEPATCH
+#endif
+
+#endif /* __ASM_LIVEPATCH_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 5ee07ee..7614990 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -35,6 +35,7 @@ arm64-obj-$(CONFIG_KGDB) += kgdb.o
arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
arm64-obj-$(CONFIG_PCI)+= pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
+arm64-obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/livepatch.c b/arch/arm64/kernel/livepatch.c
new file mode 100644
index 000..abe4947
--- /dev/null
+++ b/arch/arm64/kernel/livepatch.c
@@ -0,0 +1,68 @@
+/*
+ * livepatch.c - arm64-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2015 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * klp_write_module_reloc() - write a relocation in a module
+ * @mod: module in which the section to be modified is found
+ * @type: ELF relocation type (see asm/elf.h)
+ * @loc: address that the relocation should be written to
+ * @value: relocation value (sym address + addend)
+ *
+ * This function writes a relocation to the specified location for
+ * a particular module.
+ */
+int klp_write_module_reloc(struct module *mod, unsigned long type,
+ unsigned long loc, unsigned long value)
+{
+ unsigned long core = (unsigned long)mod->module_core;
+ unsigned long core_ro_size = mod->core_ro_size;
+ unsigned long core_size = mod->core_size;
+ bool readonly;
+ u32 new;
+ int ret;
+
+ switch (type) {
+ case R_AARCH64_NONE:
+ return 0;
+ case R_AARCH64_CALL26:
+ break;
+ default:
+ /* unsupported relocation type */
+ return -EINVAL;
+ }
+
+ if (loc < core || loc >= core + core_size)
+ /* loc does not point to any symbol inside the module */
+ return -EINVAL;
+
+ if (loc < core + core_ro_size)
+ readonly = true;
+ else
+ readonly = false;
+
+ if (readonly)
+ set_memory_rw(loc & PAGE_MASK, 1);
+
+ new = aarch64_insn_gen_branch_imm(loc, value,
+ AARCH64_INSN_BRANCH_NOLINK);
+ ret = aarch64_insn_patch_text_nosync((void *)loc, new);
+
+ if (readonly)
+
[RFC 2/4] livepatch: adjust a patched function's address
The existing livepatch code assumes that a fentry call is inserted before
a function prolog by -mfentry option of gcc. But the location of mcount()
can be identified by using ftrace_lookup_mcount(), and which eventually
allows arch's which don't support -mfentry option, like arm64, to support
livepatch.
This patch modifies core and x86 code before adding livepatch support for
arm64.
Signed-off-by: AKASHI Takahiro
---
arch/x86/include/asm/livepatch.h |5 +
include/linux/livepatch.h|2 ++
kernel/livepatch/core.c | 16
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index a455a53..914954a 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -39,6 +39,11 @@ static inline void klp_arch_set_pc(struct pt_regs *regs,
unsigned long ip)
{
regs->ip = ip;
}
+
+static inline unsigned long klp_arch_lookup_mcount(unsigned long addr)
+{
+ return addr;
+}
#else
#error Live patching support is disabled; check CONFIG_LIVEPATCH
#endif
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 95023fd..fec7800 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -47,6 +47,7 @@ struct klp_func {
/* external */
const char *old_name;
void *new_func;
+ unsigned long new_func_mcount;
/*
* The old_addr field is optional and can be used to resolve
* duplicate symbol names in the vmlinux object. If this
@@ -56,6 +57,7 @@ struct klp_func {
* way to resolve the ambiguity.
*/
unsigned long old_addr;
+ unsigned long old_addr_mcount;
/* internal */
struct kobject kobj;
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 3f9f1d6..3c7c8070 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -245,6 +245,9 @@ static int klp_find_verify_func_addr(struct klp_object *obj,
ret = klp_verify_vmlinux_symbol(func->old_name,
func->old_addr);
+ if (func->old_addr && !ret)
+ func->old_addr_mcount = klp_arch_lookup_mcount(func->old_addr);
+
return ret;
}
@@ -330,7 +333,7 @@ static void notrace klp_ftrace_handler(unsigned long ip,
if (WARN_ON_ONCE(!func))
goto unlock;
- klp_arch_set_pc(regs, (unsigned long)func->new_func);
+ klp_arch_set_pc(regs, func->new_func_mcount);
unlock:
rcu_read_unlock();
}
@@ -358,7 +361,8 @@ static int klp_disable_func(struct klp_func *func)
return ret;
}
- ret = ftrace_set_filter_ip(>fops, func->old_addr, 1, 0);
+ ret = ftrace_set_filter_ip(>fops,
+ func->old_addr_mcount, 1, 0);
if (ret)
pr_warn("function unregister succeeded but failed to
clear the filter\n");
@@ -401,7 +405,8 @@ static int klp_enable_func(struct klp_func *func)
INIT_LIST_HEAD(>func_stack);
list_add_rcu(>stack_node, >func_stack);
- ret = ftrace_set_filter_ip(>fops, func->old_addr, 0, 0);
+ ret = ftrace_set_filter_ip(>fops,
+ func->old_addr_mcount, 0, 0);
if (ret) {
pr_err("failed to set ftrace filter for function '%s'
(%d)\n",
func->old_name, ret);
@@ -412,7 +417,8 @@ static int klp_enable_func(struct klp_func *func)
if (ret) {
pr_err("failed to register ftrace handler for function
'%s' (%d)\n",
func->old_name, ret);
- ftrace_set_filter_ip(>fops, func->old_addr, 1, 0);
+ ftrace_set_filter_ip(>fops,
+ func->old_addr_mcount, 1, 0);
goto err;
}
@@ -742,6 +748,8 @@ static int klp_init_func(struct klp_object *obj, struct
klp_func *func)
{
INIT_LIST_HEAD(>stack_node);
func->state = KLP_DISABLED;
+ func->new_func_mcount =
+ klp_arch_lookup_mcount((unsigned long)func->new_func);
return kobject_init_and_add(>kobj, _ktype_func,
obj->kobj, "%s", func->old_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/
[RFC 1/4] ftrace: add a helper function for livepatch
ftrace_lookup_mcount() will return an address of mcount call in a function.
Signed-off-by: AKASHI Takahiro
---
include/linux/ftrace.h |2 ++
kernel/trace/ftrace.c | 26 ++
2 files changed, 28 insertions(+)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1da6029..1d0271f 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -699,6 +699,8 @@ static inline void __ftrace_enabled_restore(int enabled)
# define trace_preempt_off(a0, a1) do { } while (0)
#endif
+extern unsigned long ftrace_lookup_mcount(unsigned long addr);
+
#ifdef CONFIG_FTRACE_MCOUNT_RECORD
extern void ftrace_init(void);
#else
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 4f22802..fcfb04f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4857,6 +4857,32 @@ static int ftrace_process_locs(struct module *mod,
return ret;
}
+unsigned long ftrace_lookup_mcount(unsigned long addr)
+{
+ struct ftrace_page *pg;
+ struct dyn_ftrace *rec;
+ char str[KSYM_SYMBOL_LEN];
+ char *modname;
+ const char *name;
+ unsigned long mcount = 0;
+ unsigned long offset;
+
+ mutex_lock(_lock);
+
+ do_for_each_ftrace_rec(pg, rec) {
+ name = kallsyms_lookup(rec->ip, NULL, , , str);
+ if (name && rec->ip == (addr + offset)) {
+ mcount = rec->ip;
+ goto out_unlock;
+ }
+ } while_for_each_ftrace_rec();
+
+ out_unlock:
+ mutex_unlock(_lock);
+
+ return mcount;
+}
+
#ifdef CONFIG_MODULES
#define next_to_ftrace_page(p) container_of(p, struct ftrace_page, next)
--
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/
[RFC 0/4] arm64: add livepatch support
This patchset enables livepatch support on arm64. Livepatch was merged in v4.0, and allows replacying a function dynamically based on ftrace framework, but it also requires -mfentry option of gcc. Currently arm64 gcc doesn't support it, but by adding a helper function to ftrace, we will be able to support livepatch on arch's which don't support this option. I submit this patchset as RFC since I'm not quite sure that I'm doing in the right way, or we should definitely support -fentry instead. Please note that I tested the feature only with livepatch-sample, and the code for DYNAMIC_TRACE_WITH_REGS is still rough-edged. To: Steven Rostedt To: Ingo Molnar To: Josh Poimboeuf To: Seth Jennings To: Jiri Kosina To: Vojtech Pavlik To: Catalin Marinas To: Will Deacon AKASHI Takahiro (4): ftrace: add a helper function for livepatch livepatch: adjust a patched function's address arm64: ftrace: add DYNAMIC_TRACE_WITH_REGS version arm64: add livepatch support arch/arm64/Kconfig |4 ++ arch/arm64/include/asm/ftrace.h|4 ++ arch/arm64/include/asm/livepatch.h | 38 +++ arch/arm64/kernel/Makefile |1 + arch/arm64/kernel/entry-ftrace.S | 124 arch/arm64/kernel/ftrace.c | 24 ++- arch/arm64/kernel/livepatch.c | 68 arch/x86/include/asm/livepatch.h |5 ++ include/linux/ftrace.h |2 + include/linux/livepatch.h |2 + kernel/livepatch/core.c| 16 +++-- kernel/trace/ftrace.c | 26 12 files changed, 309 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/include/asm/livepatch.h create mode 100644 arch/arm64/kernel/livepatch.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'
On Apr 22, 2015, at 3:34 AM, Christoph Hellwig wrote:
> On Wed, Apr 22, 2015 at 06:49:08AM +, Drokin, Oleg wrote:
>> I know this is not going to be a popular opinion with you, but sometimes
>> opening a file
>> is just too expensive. 1 RPC roudntrip to open a file and then another one
>> to close it.
> Use O_PATH to avoid this.
Hm, I guess I can open with O_PATH, but…
if (unlikely(f->f_flags & O_PATH)) {
f->f_mode = FMODE_PATH;
f->f_op = _fops;
return 0;
}
so with such an fd I am never getting into my ioctl handler, you see…
Let's suppose I overcome this somehow, still that does not completely solve my
problem
that has more dimensions.
So, imagine I have this huge file tree (common with really big filesystems),
and I want to do a one-off find
on it for whatever reason.
I do not want to pollute my dentry and inode cache with all the extra entries
because (I think) I know I will
never need them again.
So with our broken ioctl from the past that was somewhat easy - I just open a
dir, I do getdents, I get
a bunch of names and I proceed to call my ioctl on this bunch of names and get
all the info I need
(one rpc per entry, which is not all that great, but oh well) and my dentry
cache is only getting
directories, but not the files.
Now, if I convert to O_PATH (or to some other single call thing that does not
need it, like say getxattr
that might work for some subset of intended usage), I get pretty much the same
thing, but I also get dcache pollution
and in order to guard my dcache, I am getting a bunch of lustre locks (the
expensive kind of lustre locks
issued by server so that the cache stays coherent cluster wide), even if I
somehow do uncached dentries so I
can avoid the lock, there would still be that pesky LOOKUP RPC (that I would
need to somehow teach to
not just do lookup, but to bring me other interesting things, kind of like with
open intents).
This looks like it's getting out of hand rather fast.
Now, I probably can create some sort of an RPC that is "extended getdents with
attributes" and so my extended_getdents_rpc
would return me the name and a bunch of other data like file striping, stat
information and the like. This also saves me some
more RPCs, but I imagine if I try to expose that over an ioctl, you would not
be very happy with it either and I don't think
we have this sort of an extended getdents interface at the kernel too, do we
(though I think internally nfs is capable
of such a thing)?
Do you think any of this makes sense, or do you think I should just convert
this ioctl from our broken getname version to
something like user_path_at() (an exported symbol) to do the lookup+fetch
whatever info I need and immediately unhash the
resultant dentry/inode and be done with it (at least then I do not need any
tools changes).
Do you think there's something else I might be doing, but not yet realizing
this?
Thanks.
Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ethernet: myri10ge: use arch_phys_wc_add()
From: Hyong-Youb Kim Date: Fri, 24 Apr 2015 10:57:58 +0900 > X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2015 01:58:46.2847 (UTC) > X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted > X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1302 > X-Greylist: Default is to whitelist mail, not delayed by > milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 23 Apr > 2015 18:58:55 -0700 (PDT) > Content-Type: text/plain; charset="us-ascii" > Content-Disposition: inline > Subject: Re: [PATCH v3] ethernet: myri10ge: use arch_phys_wc_add() > From: Hyong-Youb Kim > To: David Miller > CC: , , , > , , , > , , , > , , , > , , > > Date: Fri, 24 Apr 2015 10:57:58 +0900 > User-Agent: Mutt/1.5.23 (2014-03-12) > > On Thu, Apr 23, 2015 at 02:28:40PM -0400, David Miller wrote: >> I can't wait forever for the driver maintainers to review this, so >> I'm applying it. > > FWIW, I replied to Luis's patch yesterday. It appears on the netdev > list and patchwork. Checked the recipient list, and it includes > netdev, but not your address. I guess I will not make that mistake > again. I saw it. You did not supply an Acked-by: or Tested-by: tag in that response. Also, if you are not going to use the email address listed in the MAINTAINERS entry for this driver, you should update it so I know what email addresses to look for to know if someone is responsible for that driver or not. 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 v2 2/7] block: loop: don't hold lo_ctl_mutex in lo_open
On Sat, Apr 11, 2015 at 7:30 PM, Ming Lei wrote:
> The lo_ctl_mutex is held for running all ioctl handlers, and
> in some ioctl handlers, ioctl_by_bdev(BLKRRPART) is called for
> rereading partitions, which requires bd_mutex.
>
> So it is easy to cause failure because trylock(bd_mutex) may
> fail inside blkdev_reread_part(), and follows the lock context:
>
> blkid or other application:
> ->open()
> ->mutex_lock(bd_mutex)
> ->lo_open()
> ->mutex_lock(lo_ctl_mutex)
>
> losetup(set fd ioctl):
> ->mutex_lock(lo_ctl_mutex)
> ->ioctl_by_bdev(BLKRRPART)
> ->trylock(bd_mutex)
>
> This patch trys to eliminate the ABBA lock dependency by removing
> lo_ctl_mutext in lo_open() with the following approach:
>
> 1) make lo_refcnt as atomic_t and avoid acquiring lo_ctl_mutex in lo_open():
> - for open vs. add/del loop, no any problem because of
> loop_index_mutex
> - freeze request queue during clr_fd, so I/O can't come until
> clearing fd is completed, like the effect of holding lo_ctl_mutex
> in lo_open
> - both open() and release() have been serialized by bd_mutex already
>
> 2) don't hold lo_ctl_mutex for decreasing/checking lo_refcnt in
> lo_release(), then lo_ctl_mutex is only required for the last release.
>
> Tested-by: Jarod Wilson
> Acked-by: Jarod Wilson
> Signed-off-by: Ming Lei
> ---
> drivers/block/loop.c | 19 +++
> drivers/block/loop.h |2 +-
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index c4fd1e4..0d9f014 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -881,7 +881,7 @@ static int loop_clr_fd(struct loop_device *lo)
> * /do something like mkfs/losetup -d causing the losetup
> -d
> * command to fail with EBUSY.
> */
> - if (lo->lo_refcnt > 1) {
> + if (atomic_read(>lo_refcnt) > 1) {
> lo->lo_flags |= LO_FLAGS_AUTOCLEAR;
> mutex_unlock(>lo_ctl_mutex);
> return 0;
> @@ -890,6 +890,9 @@ static int loop_clr_fd(struct loop_device *lo)
> if (filp == NULL)
> return -EINVAL;
>
> + /* freeze request queue during the transition */
> + blk_mq_freeze_queue(lo->lo_queue);
> +
> spin_lock_irq(>lo_lock);
> lo->lo_state = Lo_rundown;
> lo->lo_backing_file = NULL;
> @@ -921,6 +924,8 @@ static int loop_clr_fd(struct loop_device *lo)
> lo->lo_state = Lo_unbound;
> /* This is safe: open() is still holding a reference. */
> module_put(THIS_MODULE);
> + blk_mq_unfreeze_queue(lo->lo_queue);
> +
> if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
> ioctl_by_bdev(bdev, BLKRRPART, 0);
> lo->lo_flags = 0;
> @@ -1378,9 +1383,7 @@ static int lo_open(struct block_device *bdev, fmode_t
> mode)
> goto out;
> }
>
> - mutex_lock(>lo_ctl_mutex);
> - lo->lo_refcnt++;
> - mutex_unlock(>lo_ctl_mutex);
> + atomic_inc(>lo_refcnt);
> out:
> mutex_unlock(_index_mutex);
> return err;
> @@ -1391,11 +1394,10 @@ static void lo_release(struct gendisk *disk, fmode_t
> mode)
> struct loop_device *lo = disk->private_data;
> int err;
>
> - mutex_lock(>lo_ctl_mutex);
> -
> - if (--lo->lo_refcnt)
> + if (atomic_dec_return(>lo_refcnt))
> goto out;
Sorry, the above 'goto out' should be changed to 'return', I will post out
v3 after running more tests.
>
> + mutex_lock(>lo_ctl_mutex);
> if (lo->lo_flags & LO_FLAGS_AUTOCLEAR) {
> /*
> * In autoclear mode, stop the loop thread
> @@ -1648,6 +1650,7 @@ static int loop_add(struct loop_device **l, int i)
> disk->flags |= GENHD_FL_NO_PART_SCAN;
> disk->flags |= GENHD_FL_EXT_DEVT;
> mutex_init(>lo_ctl_mutex);
> + atomic_set(>lo_refcnt, 0);
> lo->lo_number = i;
> spin_lock_init(>lo_lock);
> disk->major = LOOP_MAJOR;
> @@ -1765,7 +1768,7 @@ static long loop_control_ioctl(struct file *file,
> unsigned int cmd,
> mutex_unlock(>lo_ctl_mutex);
> break;
> }
> - if (lo->lo_refcnt > 0) {
> + if (atomic_read(>lo_refcnt) > 0) {
> ret = -EBUSY;
> mutex_unlock(>lo_ctl_mutex);
> break;
> diff --git a/drivers/block/loop.h b/drivers/block/loop.h
> index 301c27f..ffb6dd6 100644
> --- a/drivers/block/loop.h
> +++ b/drivers/block/loop.h
> @@ -28,7 +28,7 @@ struct loop_func_table;
>
> struct loop_device {
> int lo_number;
> - int lo_refcnt;
> + atomic_tlo_refcnt;
> loff_t lo_offset;
> loff_t
Re: [v6] kvm/fpu: Enable fully eager restore kvm FPU
On 04/23/2015 06:57 PM, Wanpeng Li wrote:
> Cc Rik, who is doing the similar work. :)
Hi Liang,
I posted this patch earlier, which should have the same effect as
your patch on more modern systems, while not loading the FPU context
for guests that barely use it on older systems:
https://lkml.org/lkml/2015/4/23/349
I have to admit the diffstat on your patch looks very nice, but
it might be good to know what impact it has on older systems...
> On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
>> Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
>> not have performance regression, and it can simplify the code.
>>
>> When compiling kernel on westmere, the performance of eager FPU
>> is about 0.4% faster than lazy FPU.
>>
>> Signed-off-by: Liang Li
>> Signed-off-by: Xudong Hao
>> ---
>> arch/x86/include/asm/kvm_host.h | 1 -
>> arch/x86/kvm/svm.c | 22 ++--
>> arch/x86/kvm/vmx.c | 74
>> +++--
>> arch/x86/kvm/x86.c | 8 +
>> include/linux/kvm_host.h| 2 --
>> 5 files changed, 9 insertions(+), 98 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h
>> b/arch/x86/include/asm/kvm_host.h
>> index dea2e7e..5d84cc9 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -743,7 +743,6 @@ struct kvm_x86_ops {
>> void (*cache_reg)(struct kvm_vcpu *vcpu, enum kvm_reg reg);
>> unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
>> void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
>> -void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
>>
>> void (*tlb_flush)(struct kvm_vcpu *vcpu);
>>
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index ce741b8..1b3b29b 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -1087,7 +1087,6 @@ static void init_vmcb(struct vcpu_svm *svm)
>> struct vmcb_control_area *control = >vmcb->control;
>> struct vmcb_save_area *save = >vmcb->save;
>>
>> -svm->vcpu.fpu_active = 1;
>> svm->vcpu.arch.hflags = 0;
>>
>> set_cr_intercept(svm, INTERCEPT_CR0_READ);
>> @@ -1529,15 +1528,12 @@ static void update_cr0_intercept(struct vcpu_svm
>> *svm)
>> ulong gcr0 = svm->vcpu.arch.cr0;
>> u64 *hcr0 = >vmcb->save.cr0;
>>
>> -if (!svm->vcpu.fpu_active)
>> -*hcr0 |= SVM_CR0_SELECTIVE_MASK;
>> -else
>> -*hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>> -| (gcr0 & SVM_CR0_SELECTIVE_MASK);
>> +*hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>> +| (gcr0 & SVM_CR0_SELECTIVE_MASK);
>>
>> mark_dirty(svm->vmcb, VMCB_CR);
>>
>> -if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
>> +if (gcr0 == *hcr0) {
>> clr_cr_intercept(svm, INTERCEPT_CR0_READ);
>> clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
>> } else {
>> @@ -1568,8 +1564,6 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu,
>> unsigned long cr0)
>> if (!npt_enabled)
>> cr0 |= X86_CR0_PG | X86_CR0_WP;
>>
>> -if (!vcpu->fpu_active)
>> -cr0 |= X86_CR0_TS;
>> /*
>> * re-enable caching here because the QEMU bios
>> * does not do it - this results in some delay at
>> @@ -1795,7 +1789,6 @@ static void svm_fpu_activate(struct kvm_vcpu *vcpu)
>>
>> clr_exception_intercept(svm, NM_VECTOR);
>>
>> -svm->vcpu.fpu_active = 1;
>> update_cr0_intercept(svm);
>> }
>>
>> @@ -4139,14 +4132,6 @@ static bool svm_has_wbinvd_exit(void)
>> return true;
>> }
>>
>> -static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
>> -{
>> -struct vcpu_svm *svm = to_svm(vcpu);
>> -
>> -set_exception_intercept(svm, NM_VECTOR);
>> -update_cr0_intercept(svm);
>> -}
>> -
>> #define PRE_EX(exit) { .exit_code = (exit), \
>> .stage = X86_ICPT_PRE_EXCEPT, }
>> #define POST_EX(exit) { .exit_code = (exit), \
>> @@ -4381,7 +4366,6 @@ static struct kvm_x86_ops svm_x86_ops = {
>> .cache_reg = svm_cache_reg,
>> .get_rflags = svm_get_rflags,
>> .set_rflags = svm_set_rflags,
>> -.fpu_deactivate = svm_fpu_deactivate,
>>
>> .tlb_flush = svm_flush_tlb,
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index f5e8dce..811a666 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -1567,7 +1567,7 @@ static void update_exception_bitmap(struct kvm_vcpu
>> *vcpu)
>> u32 eb;
>>
>> eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
>> - (1u << NM_VECTOR) | (1u << DB_VECTOR);
>> + (1u << DB_VECTOR);
>> if ((vcpu->guest_debug &
>> (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
>> (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
>> @@ -1576,8 +1576,6 @@ static void update_exception_bitmap(struct kvm_vcpu
>> *vcpu)
>> eb = ~0;
>> if (enable_ept)
>> eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
>> -if (vcpu->fpu_active)
Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue
On Thu, Apr 23, 2015 at 7:15 PM, Andy Lutomirski wrote: > AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET > with SS == 0 results in an invalid usermode state in which SS is > apparently equal to __USER_DS but causes #SS if used. > > Work around the issue by replacing NULL SS values with __KERNEL_DS > in __switch_to, thus ensuring that SYSRET never happens with SS set > to NULL. > > This was exposed by a recent vDSO cleanup. > > Fixes: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss > Signed-off-by: Andy Lutomirski > --- > > Tested only on Intel, which isn't very interesting. I'll tidy up > and send a test case, too, once Borislav confirms that it works. > > Please don't actually apply this until we're sure we understand the > scope of the issue. If this doesn't affect SYSRETQ, then we might > to fix it on before SYSRETL to avoid impacting 64-bit processes > at all. Even if the issue affects SYSRETQ, it could be that we don't care. If the extent of the info leak is whether we context switched during a 64-bit syscall to a non-syscall context, then this is basically uninteresting. In that case, we could either ignore the 64-bit issue entirely or fix it the other way: force SS to NULL on context switch (much faster, I presume) and fix it up before SYSRETL as Denys suggested. We clearly don't have a spate of crashes in programs that do SYSCALL from a 64-bit CS and then far jump/return to a 32-bit CS without first reloading SS, since this bug has been here forever. I agree that the issue is ugly (if it exists in the first place), but maybe we don't need to fix it. Thoughts? --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/
RE: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Thursday, April 23, 2015 10:10 PM
>
> On Thu, 2015-04-23 at 08:30 +, Kweh, Hock Leong wrote:
> > > -Original Message-
> > > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com]
> > > Sent: Wednesday, April 22, 2015 11:19 PM
> > >
> > >
> > > Yes, I think we've all agreed we can do it ... it's now a question of
> > > whether
> we
> > > can stomach the ick factor of actually initiating a transaction in close
> > > ... I'm
> still
> > > feeling queasy.
> >
> > The file "close" here can I understand that the file system will call the
> "release"
> > function at the file_operations struct?
> > http://lxr.free-electrons.com/source/include/linux/fs.h#L1538
> >
> > So, James you are meaning that we could initiating the update transaction
> > inside the f_ops->release() and return the error code if update failed in
> > this
> > function?
>
> Well, that's what I was thinking. However the return value of ->release
> doesn't get propagated in sys_close (or indeed anywhere ... no idea why
> it returns an int) thanks to the task work additions, so we'd actually
> have to use the operation whose value is propagated in sys_close() which
> turns out to be flush.
>
> James
>
Okay, I think I got you. Just to double check for in case: you are meaning
to implement it at f_ops->flush() instead of f_ops->release().
Thanks & Regards,
Wilson
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [LKP] [RAID5] 878ee679279: -1.8% vmstat.io.bo, +40.5% perf-stat.LLC-load-misses
On Thu, 23 Apr 2015 14:55:59 +0800 Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://neil.brown.name/md for-next
> commit 878ee6792799e2f88bdcac329845efadb205252f ("RAID5: batch adjacent full
> stripe write")
Hi,
is there any chance that you could explain what some of this means?
There is lots of data and some very pretty graphs, but no explanation.
Which numbers are "good", which are "bad"? Which is "worst".
What do the graphs really show? and what would we like to see in them?
I think it is really great that you are doing this testing and reporting the
results. It's just so sad that I completely fail to understand them.
Thanks,
NeilBrown
>
>
> testbox/testcase/testparams: lkp-st02/dd-write/300-5m-11HDD-RAID5-cfq-xfs-1dd
>
> a87d7f782b47e030 878ee6792799e2f88bdcac3298
> --
> %stddev %change %stddev
> \ |\
> 59035 ± 0% +18.4% 69913 ± 1% softirqs.SCHED
> 1330 ± 10% +17.4% 1561 ± 4% slabinfo.kmalloc-512.num_objs
> 1330 ± 10% +17.4% 1561 ± 4% slabinfo.kmalloc-512.active_objs
> 305908 ± 0% -1.8% 300427 ± 0% vmstat.io.bo
> 1 ± 0%+100.0% 2 ± 0% vmstat.procs.r
> 8266 ± 1% -15.7% 6968 ± 0% vmstat.system.cs
> 14819 ± 0% -2.1% 14503 ± 0% vmstat.system.in
> 18.20 ± 6% +10.2% 20.05 ± 4%
> perf-profile.cpu-cycles.raid_run_ops.handle_stripe.handle_active_stripes.raid5d.md_thread
> 1.94 ± 9% +90.6% 3.70 ± 9%
> perf-profile.cpu-cycles.async_xor.raid_run_ops.handle_stripe.handle_active_stripes.raid5d
> 0.00 ± 0% +Inf% 25.18 ± 3%
> perf-profile.cpu-cycles.handle_active_stripes.isra.45.raid5d.md_thread.kthread.ret_from_fork
> 0.00 ± 0% +Inf% 14.14 ± 4%
> perf-profile.cpu-cycles.async_copy_data.isra.42.raid_run_ops.handle_stripe.handle_active_stripes.raid5d
> 1.79 ± 7%+102.9% 3.64 ± 9%
> perf-profile.cpu-cycles.xor_blocks.async_xor.raid_run_ops.handle_stripe.handle_active_stripes
> 3.09 ± 4% -10.8% 2.76 ± 4%
> perf-profile.cpu-cycles.get_active_stripe.make_request.md_make_request.generic_make_request.submit_bio
> 0.80 ± 14% +28.1% 1.02 ± 10%
> perf-profile.cpu-cycles.mutex_lock.xfs_file_buffered_aio_write.xfs_file_write_iter.new_sync_write.vfs_write
> 14.78 ± 6%-100.0% 0.00 ± 0%
> perf-profile.cpu-cycles.async_copy_data.isra.38.raid_run_ops.handle_stripe.handle_active_stripes.raid5d
> 25.68 ± 4%-100.0% 0.00 ± 0%
> perf-profile.cpu-cycles.handle_active_stripes.isra.41.raid5d.md_thread.kthread.ret_from_fork
> 1.23 ± 5%+140.0% 2.96 ± 7%
> perf-profile.cpu-cycles.xor_sse_5_pf64.xor_blocks.async_xor.raid_run_ops.handle_stripe
> 2.62 ± 6% -95.6% 0.12 ± 33%
> perf-profile.cpu-cycles.analyse_stripe.handle_stripe.handle_active_stripes.raid5d.md_thread
> 0.96 ± 9% +17.5% 1.12 ± 2%
> perf-profile.cpu-cycles.xfs_ilock.xfs_file_buffered_aio_write.xfs_file_write_iter.new_sync_write.vfs_write
> 1.461e+10 ± 0% -5.3% 1.384e+10 ± 1% perf-stat.L1-dcache-load-misses
> 3.688e+11 ± 0% -2.7% 3.59e+11 ± 0% perf-stat.L1-dcache-loads
> 1.124e+09 ± 0% -27.7% 8.125e+08 ± 0% perf-stat.L1-dcache-prefetches
> 2.767e+10 ± 0% -1.8% 2.717e+10 ± 0% perf-stat.L1-dcache-store-misses
> 2.352e+11 ± 0% -2.8% 2.287e+11 ± 0% perf-stat.L1-dcache-stores
> 6.774e+09 ± 0% -2.3% 6.62e+09 ± 0% perf-stat.L1-icache-load-misses
> 5.571e+08 ± 0% +40.5% 7.826e+08 ± 1% perf-stat.LLC-load-misses
> 6.263e+09 ± 0% -13.7% 5.407e+09 ± 1% perf-stat.LLC-loads
> 1.914e+11 ± 0% -4.2% 1.833e+11 ± 0% perf-stat.branch-instructions
> 1.145e+09 ± 2% -5.6% 1.081e+09 ± 0% perf-stat.branch-load-misses
> 1.911e+11 ± 0% -4.3% 1.829e+11 ± 0% perf-stat.branch-loads
> 1.142e+09 ± 2% -5.1% 1.083e+09 ± 0% perf-stat.branch-misses
> 1.218e+09 ± 0% +19.8% 1.46e+09 ± 0% perf-stat.cache-misses
> 2.118e+10 ± 0% -5.2% 2.007e+10 ± 0% perf-stat.cache-references
>2510308 ± 1% -15.7%2115410 ± 0% perf-stat.context-switches
> 39623 ± 0% +22.1% 48370 ± 1% perf-stat.cpu-migrations
> 4.179e+08 ± 40%+165.7% 1.111e+09 ± 35% perf-stat.dTLB-load-misses
> 3.684e+11 ± 0% -2.5% 3.592e+11 ± 0% perf-stat.dTLB-loads
> 1.232e+08 ± 15% +62.5% 2.002e+08 ± 27% perf-stat.dTLB-store-misses
> 2.348e+11 ± 0% -2.5% 2.288e+11 ± 0% perf-stat.dTLB-stores
>3577297 ± 2% +8.7%3888986 ± 1% perf-stat.iTLB-load-misses
> 1.035e+12 ± 0% -3.5% 9.988e+11 ± 0% perf-stat.iTLB-loads
> 1.036e+12 ± 0% -3.7% 9.978e+11 ± 0% perf-stat.instructions
>594 ± 30%+130.3% 1369 ± 13%
>
[PATCH] context_tracking: remove local_irq_save from __acct_update_integrals
The function __acct_update_integrals() is called both from irq context
and task context. This creates a race where irq context can advance
tsk->acct_timexpd to a value larger than time, leading to a negative
value, which causes a divide error. See commit 6d5b5acca9e5
("Fix fixpoint divide exception in acct_update_integrals")
In 2012, __acct_update_integrals() was changed to get utime and stime
as function parameters. This re-introduced the bug, because an irq
can hit in-between the call to task_cputime() and where irqs actually
get disabled.
However, this race condition was originally reproduced on Hercules,
and I have not seen any reports of it re-occurring since it was
re-introduced 3 years ago.
On the other hand, the irq disabling and re-enabling, which no longer
even protects us against the race today, show up prominently in the
perf profile of a program that makes a very large number of system calls
in a short period of time, when nohz_full= (and context tracking) is
enabled.
This patch replaces the (now ineffective) irq blocking with a cheaper
way to test for the race condition, and speeds up my microbenchmark
with 10 million iterations:
run timesystem time
vanilla 5.49s 2.08s
patch 5.21s 1.92s
The above shows a reduction in system time of about 7%.
The standard deviation is mostly in the third digit after
the decimal point.
Cc: Andy Lutomirsky
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Heiko Carstens
Cc: Luiz Capitulino
Cc: Marcelo Tosatti
Cc: Clark Williams
Signed-off-by: Rik van Riel
---
kernel/tsacct.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 975cb49e32bf..0b967f116a6b 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -126,23 +126,29 @@ static void __acct_update_integrals(struct task_struct
*tsk,
if (likely(tsk->mm)) {
cputime_t time, dtime;
struct timeval value;
- unsigned long flags;
u64 delta;
- local_irq_save(flags);
time = stime + utime;
dtime = time - tsk->acct_timexpd;
+ /*
+* This code is called both from irq context and from
+* task context. There is a race where irq context advances
+* tsk->acct_timexpd to a value larger than time, creating
+* a negative value. In that case, the irq has already
+* updated the statistics.
+*/
+ if (unlikely((signed long)dtime <= 0))
+ return;
+
jiffies_to_timeval(cputime_to_jiffies(dtime), );
delta = value.tv_sec;
delta = delta * USEC_PER_SEC + value.tv_usec;
if (delta == 0)
- goto out;
+ return;
tsk->acct_timexpd = time;
tsk->acct_rss_mem1 += delta * get_mm_rss(tsk->mm);
tsk->acct_vm_mem1 += delta * tsk->mm->total_vm;
- out:
- local_irq_restore(flags);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue
AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET
with SS == 0 results in an invalid usermode state in which SS is
apparently equal to __USER_DS but causes #SS if used.
Work around the issue by replacing NULL SS values with __KERNEL_DS
in __switch_to, thus ensuring that SYSRET never happens with SS set
to NULL.
This was exposed by a recent vDSO cleanup.
Fixes: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
Signed-off-by: Andy Lutomirski
---
Tested only on Intel, which isn't very interesting. I'll tidy up
and send a test case, too, once Borislav confirms that it works.
Please don't actually apply this until we're sure we understand the
scope of the issue. If this doesn't affect SYSRETQ, then we might
to fix it on before SYSRETL to avoid impacting 64-bit processes
at all.
arch/x86/ia32/ia32entry.S | 5 +
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/kernel/cpu/amd.c | 3 +++
arch/x86/kernel/entry_64.S| 6 ++
arch/x86/kernel/process_64.c | 25 +
5 files changed, 40 insertions(+)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 3c9fadf8b95c..ff519ea8b054 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -421,6 +421,11 @@ sysretl_from_sys_call:
* cs and ss are loaded from MSRs.
* (Note: 32bit->32bit SYSRET is different: since r11
* does not exist, it merely sets eflags.IF=1).
+*
+* NB: On AMD CPUs with the X86_BUG_SYSRET_SS_ATTRS bug, the ss
+* descriptor is not reinitialized. This means that we must
+* avoid SYSRET with SS == NULL. We prevent that from happening
+* by reloading SS in __switch_to.
*/
USERGS_SYSRET32
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 854c04b3c9c2..7e244f626301 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -257,6 +257,7 @@
#define X86_BUG_11AP X86_BUG(5) /* Bad local APIC aka 11AP */
#define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */
#define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required
before MONITOR */
+#define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up SS
attrs */
#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index fd470ebf924e..e4cf63301ff4 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -720,6 +720,9 @@ static void init_amd(struct cpuinfo_x86 *c)
if (!cpu_has(c, X86_FEATURE_3DNOWPREFETCH))
if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM))
set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
+
+ /* AMD CPUs don't reset SS attributes on SYSRET */
+ set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 0034012d04ea..ffeaed0534d8 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -295,6 +295,12 @@ system_call_fastpath:
* rflags from r11 (but RF and VM bits are forced to 0),
* cs and ss are loaded from MSRs.
* Restoration of rflags re-enables interrupts.
+*
+* NB: On AMD CPUs with the X86_BUG_SYSRET_SS_ATTRS bug, the ss
+* descriptor is not reinitialized. This means that we should
+* avoid SYSRET with SS == NULL. We prevent that from happening
+* by reloading SS in __switch_to. (Actually detecting the failure
+* in 64-bit userspace is tricky but can be done.)
*/
USERGS_SYSRET64
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4baaa972f52a..919d6c2abded 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -419,6 +419,31 @@ __switch_to(struct task_struct *prev_p, struct task_struct
*next_p)
task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
__switch_to_xtra(prev_p, next_p, tss);
+ if (static_cpu_has_bug(X86_BUG_SYSRET_SS_ATTRS)) {
+ /*
+* AMD CPUs have a misfeature: SYSRET sets the SS selector
+* but does not update the cached descriptor. As a result,
+* if we do SYSRET while SS is NULL, we'll end up in user
+* mode with SS apparently equal to __USER_DS but actually
+* unusable.
+*
+* The straightforward workaround would be to fix it up
+* just before SYSRET, but that would slow down the system
+* call fast paths. Instead, we ensure that SS is never NULL
+* in system call context. We do this by replacing NULL
+* SS selectors at every context switch. SYSCALL sets up
+* a valid SS, so the
Input: keyboard/Trackpad support for MacBookPro 12,1
My new MacBook Pro (Retina, 13-inch, Early 2015, Model Identifier: MacBookPro12,1) with ForceTouch trackpad has a new Product ID 0x0273, which I think is the ISO, and the other should be ANSI:0x0272, JIS:0x0274, but I'm not sure, anyone can confirm this? Apple Internal Keyboard / Trackpad: Product ID: 0x0273 Vendor ID:0x05ac (Apple Inc.) Version: 6.22 Serial Number:xx Manufacturer: Apple Inc. Location ID: 0x0100 However, after I add the Product ID as usual, the keyboard works fine, but the trackpad doesn't work at all, after checking the Info by lsusb, the trackpad seems to fallback to the old geyser way because it reports a wMaxPacketSize 0x0040 1x 64 bytes, I don't have much knowledge about trackpad driver, is there anyone that can figer out what the driver protocol is? # lsusb -v -s 001:003 Bus 001 Device 003: ID 05ac:0273 Apple, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x05ac Apple, Inc. idProduct 0x0273 bcdDevice6.22 iManufacturer 1 Apple Inc. iProduct2 Apple Internal Keyboard / Trackpad iSerial 3 D3H5107H8T1GHJGA64KS bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 141 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 4 Keyboard / Trackpad bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 5 Device Management HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 27 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 6 Keyboard / Boot HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode 33 US bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 182 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 7 Trackpad / Boot HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 110 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None
linux-next: manual merge of the kvm tree with the powerpc-merge-mpe tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in
arch/powerpc/kvm/book3s_hv_rm_mmu.c between commit dac565706791 ("KVM:
PPC: Remove page table walk helpers") from the powerpc-merge-mpe tree
and commit a4bd6eb07ca7 ("KVM: PPC: Book3S HV: Add helpers for
lock/unlock hpte") from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/powerpc/kvm/book3s_hv_rm_mmu.c
index d839f08cb903,f6bf0b1de6d7..
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@@ -134,12 -131,25 +134,6 @@@ static void remove_revmap_chain(struct
unlock_rmap(rmap);
}
- static inline void unlock_hpte(__be64 *hpte, unsigned long hpte_v)
-static pte_t lookup_linux_pte_and_update(pgd_t *pgdir, unsigned long hva,
-int writing, unsigned long *pte_sizep)
--{
- asm volatile(PPC_RELEASE_BARRIER "" : : : "memory");
- hpte[0] = cpu_to_be64(hpte_v);
- pte_t *ptep;
- unsigned long ps = *pte_sizep;
- unsigned int hugepage_shift;
-
- ptep = find_linux_pte_or_hugepte(pgdir, hva, _shift);
- if (!ptep)
- return __pte(0);
- if (hugepage_shift)
- *pte_sizep = 1ul << hugepage_shift;
- else
- *pte_sizep = PAGE_SIZE;
- if (ps > *pte_sizep)
- return __pte(0);
- return kvmppc_read_update_linux_pte(ptep, writing, hugepage_shift);
--}
--
long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
long pte_index, unsigned long pteh, unsigned long ptel,
pgd_t *pgdir, bool realmode, unsigned long *pte_idx_ret)
pgp6C4naP2n5T.pgp
Description: OpenPGP digital signature
Re: [GIT PULL 0/4] perf/urgent fixes
Em Fri, Apr 24, 2015 at 11:02:18AM +0900, Namhyung Kim escreveu:
> Hi Arnaldo,
>
> I've set up some docker containers for build test, and found a couple
> of failures.. It seems David's kmem build fix ("perf kmem: Fix
> compiles on RHEL6/OL6") which is in your perf/core branch also needs
> to be in perf/urgent. Sorry about the kmem breakages..
>
> And I also found this..
I can send those tomorrow, in another pull request to Ingo. I noticed a
few on a RHEL5 machine I tested today, in libtraceevent even, I guess
you was on the CC list for that bug report.
- Arnaldo
>
> >From 581ae7f48c89377755391c3f95637a1d48eefc73 Mon Sep 17 00:00:00 2001
> From: Namhyung Kim
> Date: Fri, 24 Apr 2015 10:45:16 +0900
> Subject: [PATCH] tools lib traceevent: Fix build failure on 32-bit arch
>
> In my i386 build, it failed like this:
>
> CC event-parse.o
> event-parse.c: In function 'print_str_arg':
> event-parse.c:3868:5: warning: format '%lu' expects argument of type 'long
> unsigned int',
> but argument 3 has type 'uint64_t' [-Wformat]
>
> Cc: Javi Merino
> Signed-off-by: Namhyung Kim
> ---
> tools/lib/traceevent/event-parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/traceevent/event-parse.c
> b/tools/lib/traceevent/event-parse.c
> index 12a7e2a40c89..aa21bd55bd8a 100644
> --- a/tools/lib/traceevent/event-parse.c
> +++ b/tools/lib/traceevent/event-parse.c
> @@ -3865,7 +3865,7 @@ static void print_str_arg(struct trace_seq *s, void
> *data, int size,
> } else if (el_size == 4) {
> trace_seq_printf(s, "%u", *(uint32_t *)num);
> } else if (el_size == 8) {
> - trace_seq_printf(s, "%lu", *(uint64_t *)num);
> + trace_seq_printf(s, "%"PRIu64, *(uint64_t
> *)num);
> } else {
> trace_seq_printf(s, "BAD SIZE:%d 0x%x",
>el_size, *(uint8_t *)num);
> --
> 2.3.4
>
>
> Thanks,
> Namhyung
>
>
> On Thu, Apr 23, 2015 at 07:03:06PM -0300, Arnaldo Carvalho de Melo wrote:
> > Hi Ingo,
> >
> > Please consider pulling,
> >
> > - Arnaldo
> >
> > The following changes since commit 0140e6141e4f1d4b15fb469e6912b0e71b7d1cc2:
> >
> > perf/x86/intel/uncore: Move PCI IDs for IMC to uncore driver (2015-04-22
> > 08:29:19 +0200)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> > tags/perf-urgent-for-mingo
> >
> > for you to fetch changes up to de28c15daf60e9625bece22f13a091fac8d05f1d:
> >
> > tools lib api: Undefine _FORTIFY_SOURCE before setting it (2015-04-23
> > 17:08:23 -0300)
> >
> >
> > perf/urgent fixes:
> >
> > User visible:
> >
> > - Enable events when doing system wide 'trace' and starting a
> > workload, e.g:
> >
> ># trace -a sleep 1
> >
> > now it matches the pattern in 'record' and will show envents
> > instead of sitting doing nothing while waiting for the started
> > workload to finish (Arnaldo Carvalho de Melo)
> >
> > - Disable and drain events when forked 'trace' workload ends
> > making sure we notice the end of the workload instead of
> > trying to keep up with the seemingly neverending flux of
> > system wide events (Arnaldo Carvalho de Melo)
> >
> > Infrastructure:
> >
> > - Fix the build on 32-bit ARM by consistently use PRIu64 for printing u64
> > values in 'perf kmem' (Will Deacon)
> >
> > - Undefine _FORTIFY_SOURCE before setting it in tools/perf/api, fixing the
> > build on
> > Hardened Gentoo systems (Bobby Powers)
> >
> > Signed-off-by: Arnaldo Carvalho de Melo
> >
> >
> > Arnaldo Carvalho de Melo (2):
> > perf trace: Enable events when doing system wide tracing and starting
> > a workload
> > perf trace: Disable events and drain events when forked workload ends
> >
> > Bobby Powers (1):
> > tools lib api: Undefine _FORTIFY_SOURCE before setting it
> >
> > Will Deacon (1):
> > perf kmem: Consistently use PRIu64 for printing u64 values
> >
> > tools/lib/api/Makefile | 2 +-
> > tools/perf/builtin-kmem.c | 4 ++--
> > tools/perf/builtin-trace.c | 10 --
> > 3 files changed, 11 insertions(+), 5 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] elevator: fix memory leak in ->elevator_init_fn
In ->elevator_init_fn, if we fail to call kzalloc_node, we should release
elevator queue space which is allocated previously, otherwise it will cause
memory leak.
Signed-off-by: Chao Yu
---
block/cfq-iosched.c | 1 +
block/deadline-iosched.c | 1 +
block/noop-iosched.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 5da8e6e..2793fb7 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -4391,6 +4391,7 @@ static int cfq_init_queue(struct request_queue *q, struct
elevator_type *e)
cfqd = kzalloc_node(sizeof(*cfqd), GFP_KERNEL, q->node);
if (!cfqd) {
kobject_put(>kobj);
+ kfree(eq);
return -ENOMEM;
}
eq->elevator_data = cfqd;
diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c
index a753df2..bc6d7d9 100644
--- a/block/deadline-iosched.c
+++ b/block/deadline-iosched.c
@@ -349,6 +349,7 @@ static int deadline_init_queue(struct request_queue *q,
struct elevator_type *e)
dd = kzalloc_node(sizeof(*dd), GFP_KERNEL, q->node);
if (!dd) {
kobject_put(>kobj);
+ kfree(eq);
return -ENOMEM;
}
eq->elevator_data = dd;
diff --git a/block/noop-iosched.c b/block/noop-iosched.c
index 3de89d4..1399c78 100644
--- a/block/noop-iosched.c
+++ b/block/noop-iosched.c
@@ -71,6 +71,7 @@ static int noop_init_queue(struct request_queue *q, struct
elevator_type *e)
nd = kmalloc_node(sizeof(*nd), GFP_KERNEL, q->node);
if (!nd) {
kobject_put(>kobj);
+ kfree(eq);
return -ENOMEM;
}
eq->elevator_data = nd;
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] kdbus for 4.1-rc1
On Thu, Apr 23, 2015 at 09:30:13PM +0200, Greg Kroah-Hartman wrote: > On Thu, Apr 23, 2015 at 01:42:25PM -0400, Stephen Smalley wrote: > > On 04/23/2015 01:16 PM, Greg Kroah-Hartman wrote: > > > The binder developers at Samsung have stated that the implementation we > > > have here works for their model as well, so I guess that is some kind of > > > verification it's not entirely tied to D-Bus. They have plans on > > > dropping the existing binder kernel code and using the kdbus code > > > instead when it is merged. > > > > Where do things stand wrt LSM hooks for kdbus? I don't see any security > > hook calls in the kdbus tree except for the purpose of metadata > > collection of process security labels. But nothing for enforcing MAC > > over kdbus IPC. binder has a set of security hooks for that purpose, so > > it would be a regression wrt MAC enforcement to switch from binder to > > kdbus without equivalent checking there. > > There was a set of LSM hooks proposed for kdbus posted by Karol > Lewandowsk last October, and it also included SELinux and Smack patches. > They were going to be refreshed based on the latest code changes, but I > haven't seen them posted, or I can't seem to find them in my limited > email archive. We have been waiting for right moment with these. :-) > Karol, what's the status of them? I have handed patchset over to Paul Osmialowski who started rework it for v4 relatively recently. I think it shouldn't be that hard to post updated version... Paul? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL 0/4] perf/urgent fixes
Hi Arnaldo,
I've set up some docker containers for build test, and found a couple
of failures.. It seems David's kmem build fix ("perf kmem: Fix
compiles on RHEL6/OL6") which is in your perf/core branch also needs
to be in perf/urgent. Sorry about the kmem breakages..
And I also found this..
>From 581ae7f48c89377755391c3f95637a1d48eefc73 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 24 Apr 2015 10:45:16 +0900
Subject: [PATCH] tools lib traceevent: Fix build failure on 32-bit arch
In my i386 build, it failed like this:
CC event-parse.o
event-parse.c: In function 'print_str_arg':
event-parse.c:3868:5: warning: format '%lu' expects argument of type 'long
unsigned int',
but argument 3 has type 'uint64_t' [-Wformat]
Cc: Javi Merino
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/event-parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 12a7e2a40c89..aa21bd55bd8a 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3865,7 +3865,7 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
} else if (el_size == 4) {
trace_seq_printf(s, "%u", *(uint32_t *)num);
} else if (el_size == 8) {
- trace_seq_printf(s, "%lu", *(uint64_t *)num);
+ trace_seq_printf(s, "%"PRIu64, *(uint64_t
*)num);
} else {
trace_seq_printf(s, "BAD SIZE:%d 0x%x",
el_size, *(uint8_t *)num);
--
2.3.4
Thanks,
Namhyung
On Thu, Apr 23, 2015 at 07:03:06PM -0300, Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 0140e6141e4f1d4b15fb469e6912b0e71b7d1cc2:
>
> perf/x86/intel/uncore: Move PCI IDs for IMC to uncore driver (2015-04-22
> 08:29:19 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-urgent-for-mingo
>
> for you to fetch changes up to de28c15daf60e9625bece22f13a091fac8d05f1d:
>
> tools lib api: Undefine _FORTIFY_SOURCE before setting it (2015-04-23
> 17:08:23 -0300)
>
>
> perf/urgent fixes:
>
> User visible:
>
> - Enable events when doing system wide 'trace' and starting a
> workload, e.g:
>
># trace -a sleep 1
>
> now it matches the pattern in 'record' and will show envents
> instead of sitting doing nothing while waiting for the started
> workload to finish (Arnaldo Carvalho de Melo)
>
> - Disable and drain events when forked 'trace' workload ends
> making sure we notice the end of the workload instead of
> trying to keep up with the seemingly neverending flux of
> system wide events (Arnaldo Carvalho de Melo)
>
> Infrastructure:
>
> - Fix the build on 32-bit ARM by consistently use PRIu64 for printing u64
> values in 'perf kmem' (Will Deacon)
>
> - Undefine _FORTIFY_SOURCE before setting it in tools/perf/api, fixing the
> build on
> Hardened Gentoo systems (Bobby Powers)
>
> Signed-off-by: Arnaldo Carvalho de Melo
>
>
> Arnaldo Carvalho de Melo (2):
> perf trace: Enable events when doing system wide tracing and starting a
> workload
> perf trace: Disable events and drain events when forked workload ends
>
> Bobby Powers (1):
> tools lib api: Undefine _FORTIFY_SOURCE before setting it
>
> Will Deacon (1):
> perf kmem: Consistently use PRIu64 for printing u64 values
>
> tools/lib/api/Makefile | 2 +-
> tools/perf/builtin-kmem.c | 4 ++--
> tools/perf/builtin-trace.c | 10 --
> 3 files changed, 11 insertions(+), 5 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ethernet: myri10ge: use arch_phys_wc_add()
On Thu, Apr 23, 2015 at 02:28:40PM -0400, David Miller wrote: > I can't wait forever for the driver maintainers to review this, so > I'm applying it. FWIW, I replied to Luis's patch yesterday. It appears on the netdev list and patchwork. Checked the recipient list, and it includes netdev, but not your address. I guess I will not make that mistake again. https://patchwork.ozlabs.org/patch/463481/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scripts/gdb: Add command to check list consistency
Add a gdb script to verify the consistency of lists.
Signed-off-by: Thiébaud Weksteen
---
Implement suggestions from Jan.
Changes in v2:
- Add copyright line
- Rename check_list to list_check
- Remove casting and only accept (struct list_head) object
- Add error message if argument is missing
- Reformat error messages to include address of nodes
Example of use:
(gdb) lx-list-check workqueues
Starting with: {next = 0xf3aea5a8, prev = 0xf580e668}
list is consistent: 30 node(s)
(gdb) set *((int *) 0xf3934908) = 0x0
(gdb) lx-list-check workqueues
Starting with: {next = 0xf3aea5a8, prev = 0xf580e668}
next is not accessible: current@0xf3934908={next = 0x0, prev = 0xf3aea5a8}
(gdb) set *((int *) 0xf3934908) = 0xdeadbeef
(gdb) lx-list-check workqueues
Starting with: {next = 0xf3aea5a8, prev = 0xf580e668}
next.prev != current: current@0xf3934908={next = 0xdeadbeef, prev = 0xf3aea5a8}
next@0xdeadbeef={next = 0x0, prev = 0x0}
(gdb) set *((int *) 0xf3934908) = 0xf537f188
(gdb) lx-list-check workqueues
Starting with: {next = 0xf3aea5a8, prev = 0xf580e668}
list is consistent: 30 node(s)
scripts/gdb/linux/lists.py | 89 ++
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 90 insertions(+)
create mode 100644 scripts/gdb/linux/lists.py
diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
new file mode 100644
index 000..2a94b54
--- /dev/null
+++ b/scripts/gdb/linux/lists.py
@@ -0,0 +1,89 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# list tools
+#
+# Copyright (c) Thiebaud Weksteen, 2015
+#
+# Authors:
+# Thiebaud Weksteen
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+
+from linux import utils
+
+list_head = utils.CachedType("struct list_head")
+
+
+def list_check(head):
+nb = 0
+c = head
+if (c.type != list_head.get_type()):
+raise gdb.GdbError('The argument should be of type (struct list_head)')
+try:
+gdb.write("Starting with: {}\n".format(c))
+except gdb.MemoryError:
+gdb.write('head is not accessible\n')
+return
+while True:
+p = c['prev'].dereference()
+n = c['next'].dereference()
+try:
+if p['next'] != c.address:
+gdb.write('prev.next != current: '
+ 'current@{current_addr}={current} '
+ 'prev@{p_addr}={p}\n'.format(
+ current_addr=c.address,
+ current=c,
+ p_addr=p.address,
+ p=p,
+ ))
+return
+except gdb.MemoryError:
+gdb.write('prev is not accessible: '
+ 'current@{current_addr}={current}\n'.format(
+ current_addr=c.address,
+ current=c
+ ))
+return
+try:
+if n['prev'] != c.address:
+gdb.write('next.prev != current: '
+ 'current@{current_addr}={current} '
+ 'next@{n_addr}={n}\n'.format(
+ current_addr=c.address,
+ current=c,
+ n_addr=n.address,
+ n=n,
+ ))
+return
+except gdb.MemoryError:
+gdb.write('next is not accessible: '
+ 'current@{current_addr}={current}\n'.format(
+ current_addr=c.address,
+ current=c
+ ))
+return
+c = n
+nb += 1
+if c == head:
+gdb.write("list is consistent: {} node(s)\n".format(nb))
+return
+
+
+class LxListChk(gdb.Command):
+"""Verify a list consistency"""
+
+def __init__(self):
+super(LxListChk, self).__init__("lx-list-check", gdb.COMMAND_DATA)
+
+def invoke(self, arg, from_tty):
+argv = gdb.string_to_argv(arg)
+if len(argv) != 1:
+raise gdb.GdbError("lx-list-check takes one argument")
+list_check(gdb.parse_and_eval(argv[0]))
+
+LxListChk()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index 4848928..ce82bf5 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -28,3 +28,4 @@ else:
import linux.dmesg
import linux.tasks
import linux.cpus
+import linux.lists
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] ocfs2: use retval instead of status for checking error
The use of 'status' in __ocfs2_add_entry() can return wrong
value. Some functions' return value in __ocfs2_add_entry(),
i.e ocfs2_journal_access_di() is saved to 'status'.
But 'status' is not used in 'bail' label for returning result
of __ocfs2_add_entry().
So use retval instead of status.
Reviewed-by: Joseph Qi
Signed-off-by: Daeseok Youn
---
RESEND: missed my patch in ocfs2-devel mailing list so send it again
And also add 'Reviewed-by' line.
Previous sent message of my patch
This patch was came from 'https://lkml.org/lkml/2015/2/27/655'
This patch was needed to test but I didn't have any environment
for testing ocfs2 filesystem. But I have one, now.
(I'm too busy to make this enviroment. And qemu for this fs is difficult
for me. :-(, sorry for that)
Briefly how to set my environment for testing this fs with qemu.
1. Getting and building linux kernel with linux-next branch for x86_64
qemu.
And also options of ocfs2 related are enabled(built-in)
2. Makes own root file system with 'buildroot' project.
3. Getting and building ocfs2-tools.
Then binaries after building this tool are moved my rootfs.
4. Makes dummy disk image(5G) which will be formatted in qemu.
5. Booting qemu with rootfs image and dummy disk image.
6. mkfs.ocfs2 --fs-feature=local
this maybe possilbe to mount standalone mode.
7. tunefs.ocfs2 --fs-features=indexed-dirs,noinline-data
8. make a cluster and one node
use o2cb_ctl tool.
9. o2cb service load and initialize
# /etc/init.d/o2cb load && /etc/init.d/o2cb configure
# /etc/init.d/o2cb online
10. mount ocfs2
# mount.ocfs2
And use GDB for debugging my patch path.
Connect gdb with qemu and add breakpoint in __ocfs2_add_entry() of
fs/ocfs2/dir.c
And test my patch.
# cd
# mkdir
This how-to is not written all my work, just briefly I said.
fs/ocfs2/dir.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 990e8f7..a9513ff 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1607,7 +1607,7 @@ int __ocfs2_add_entry(handle_t *handle,
struct ocfs2_dir_entry *de, *de1;
struct ocfs2_dinode *di = (struct ocfs2_dinode *)parent_fe_bh->b_data;
struct super_block *sb = dir->i_sb;
- int retval, status;
+ int retval;
unsigned int size = sb->s_blocksize;
struct buffer_head *insert_bh = lookup->dl_leaf_bh;
char *data_start = insert_bh->b_data;
@@ -1685,25 +1685,25 @@ int __ocfs2_add_entry(handle_t *handle,
}
if (insert_bh == parent_fe_bh)
- status = ocfs2_journal_access_di(handle,
+ retval = ocfs2_journal_access_di(handle,
INODE_CACHE(dir),
insert_bh,
OCFS2_JOURNAL_ACCESS_WRITE);
else {
- status = ocfs2_journal_access_db(handle,
+ retval = ocfs2_journal_access_db(handle,
INODE_CACHE(dir),
insert_bh,
OCFS2_JOURNAL_ACCESS_WRITE);
- if (ocfs2_dir_indexed(dir)) {
- status = ocfs2_dx_dir_insert(dir,
+ if (!retval && ocfs2_dir_indexed(dir))
+ retval = ocfs2_dx_dir_insert(dir,
handle,
lookup);
- if (status) {
- mlog_errno(status);
- goto bail;
- }
- }
+ }
+
+ if (retval) {
+ mlog_errno(retval);
+ goto bail;
}
/* By now the buffer is marked for journaling */
--
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: [PATCH] elevator: fix double release for elevator module
Hi Jens and Jeff,
Thanks for your review and help! :)
Regards,
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Friday, April 24, 2015 12:49 AM
> To: Jeff Moyer; Chao Yu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] elevator: fix double release for elevator module
>
> On 04/23/2015 08:59 AM, Jeff Moyer wrote:
> > Chao Yu writes:
> >
> >> Our issue is descripted in below call path:
> >> ->elevator_init
> >> ->elevator_init_fn
> >>->{cfq,deadline,noop}_init_queue
> >> ->elevator_alloc
> >> ->kzalloc_node
> >> fail to call kzalloc_node and then put module in elevator_alloc;
> >> fail to call elevator_init_fn and then put module again in elevator_init.
> >>
> >> Remove elevator_put invoking in error path of elevator_alloc to avoid
> >> double release issue.
> >>
> >> Signed-off-by: Chao Yu
> >> ---
> >> block/elevator.c | 5 +
> >> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/block/elevator.c b/block/elevator.c
> >> index d146a5e..8985038 100644
> >> --- a/block/elevator.c
> >> +++ b/block/elevator.c
> >> @@ -157,7 +157,7 @@ struct elevator_queue *elevator_alloc(struct
> >> request_queue *q,
> >>
> >>eq = kzalloc_node(sizeof(*eq), GFP_KERNEL, q->node);
> >>if (unlikely(!eq))
> >> - goto err;
> >> + return NULL;
> >>
> >>eq->type = e;
> >>kobject_init(>kobj, _ktype);
> >> @@ -165,9 +165,6 @@ struct elevator_queue *elevator_alloc(struct
> >> request_queue *q,
> >>hash_init(eq->hash);
> >>
> >>return eq;
> >> -err:
> >> - elevator_put(e);
> >> - return NULL;
> >> }
> >> EXPORT_SYMBOL(elevator_alloc);
> >
> > You could have posted the two patches together, as they are related.
> > Anyway, looks good to me.
> >
> > Reviewed-by: Jeff Moyer
>
> Agree, it should be one patch. I've combined them, and applied the fix
> for 4.1. Thanks.
>
> --
> 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/
Re: [PATCH] ocfs2: use retval instead of status for checking error
Hi, Andrew.
Is there problem this patch to merge?
If you care about mlog_errno() cleanup, I will send another patch for that.
And also if you have any reasons this patch has not been taken,
please let me know. I will fix and test again.
Thanks.
regards,
Daeseok Youn/
2015-04-23 9:49 GMT+09:00 Joseph Qi :
> On 2015/4/19 13:43, Daeseok Youn wrote:
>> The use of 'status' in __ocfs2_add_entry() can return wrong
>> value. Some functions' return value in __ocfs2_add_entry(),
>> i.e ocfs2_journal_access_di() is saved to 'status'.
>> But 'status' is not used in 'bail' label for returning result
>> of __ocfs2_add_entry().
>>
>> So use retval instead of status.
>>
>> Signed-off-by: Daeseok Youn
>
> Reviewed-by: Joseph Qi
>> ---
>> This patch was came from 'https://lkml.org/lkml/2015/2/27/655'
>> This patch was needed to test but I didn't have any environment
>> for testing ocfs2 filesystem. But I have one, now.
>> (I'm too busy to make this enviroment. And qemu for this fs is difficult
>> for me. :-(, sorry for that)
>>
>> Briefly how to set my environment for testing this fs with qemu.
>> 1. Getting and building linux kernel with linux-next branch for x86_64 qemu.
>>And also options of ocfs2 related are enabled(built-in)
>> 2. Makes own root file system with 'buildroot' project.
>> 3. Getting and building ocfs2-tools.
>> Then binaries after building this tool are moved my rootfs.
>> 4. Makes dummy disk image(5G) which will be formatted in qemu.
>> 5. Booting qemu with rootfs image and dummy disk image.
>> 6. mkfs.ocfs2 --fs-feature=local
>> this maybe possilbe to mount standalone mode.
>> 7. tunefs.ocfs2 --fs-features=indexed-dirs,noinline-data
>> 8. make a cluster and one node
>> use o2cb_ctl tool.
>> 9. o2cb service load and initialize
>> # /etc/init.d/o2cb load && /etc/init.d/o2cb configure
>> # /etc/init.d/o2cb online
>> 10. mount ocfs2
>> # mount.ocfs2
>>
>> And use GDB for debugging my patch path.
>> Connect gdb with qemu and add breakpoint in __ocfs2_add_entry() of
>> fs/ocfs2/dir.c
>>
>> And test my patch.
>> # cd
>> # mkdir
>>
>> This how-to is not written all my work, just briefly I said.
>>
>> fs/ocfs2/dir.c | 20 ++--
>> 1 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
>> index 990e8f7..a9513ff 100644
>> --- a/fs/ocfs2/dir.c
>> +++ b/fs/ocfs2/dir.c
>> @@ -1607,7 +1607,7 @@ int __ocfs2_add_entry(handle_t *handle,
>> struct ocfs2_dir_entry *de, *de1;
>> struct ocfs2_dinode *di = (struct ocfs2_dinode *)parent_fe_bh->b_data;
>> struct super_block *sb = dir->i_sb;
>> - int retval, status;
>> + int retval;
>> unsigned int size = sb->s_blocksize;
>> struct buffer_head *insert_bh = lookup->dl_leaf_bh;
>> char *data_start = insert_bh->b_data;
>> @@ -1685,25 +1685,25 @@ int __ocfs2_add_entry(handle_t *handle,
>> }
>>
>> if (insert_bh == parent_fe_bh)
>> - status = ocfs2_journal_access_di(handle,
>> + retval = ocfs2_journal_access_di(handle,
>>
>> INODE_CACHE(dir),
>>insert_bh,
>>
>> OCFS2_JOURNAL_ACCESS_WRITE);
>> else {
>> - status = ocfs2_journal_access_db(handle,
>> + retval = ocfs2_journal_access_db(handle,
>>
>> INODE_CACHE(dir),
>>insert_bh,
>> OCFS2_JOURNAL_ACCESS_WRITE);
>>
>> - if (ocfs2_dir_indexed(dir)) {
>> - status = ocfs2_dx_dir_insert(dir,
>> + if (!retval && ocfs2_dir_indexed(dir))
>> + retval = ocfs2_dx_dir_insert(dir,
>> handle,
>> lookup);
>> - if (status) {
>> - mlog_errno(status);
>> - goto bail;
>> - }
>> - }
>> + }
>> +
>> + if (retval) {
>> + mlog_errno(retval);
>> + goto bail;
>> }
>>
>> /* By now the buffer is marked for journaling */
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
[PATCH v2 9.5/10] perf hists browser: Simplify zooming code using pstack_peek()
Now LEFT key press action can just use do_zoom_dso/thread() code to
get out of the current filter.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 9bd7b38de64c..8733d577db78 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1860,19 +1860,17 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
goto out_free_stack;
continue;
}
- top = pstack__pop(browser->pstack);
+ top = pstack__peek(browser->pstack);
if (top == >hists->dso_filter) {
- perf_hpp__set_elide(HISTC_DSO, false);
- browser->hists->dso_filter = NULL;
- hists__filter_by_dso(browser->hists);
- }
- if (top == >hists->thread_filter) {
- perf_hpp__set_elide(HISTC_THREAD, false);
- thread__zput(browser->hists->thread_filter);
- hists__filter_by_thread(browser->hists);
+ /*
+* No need to set actions->dso here since
+* it's just to remove the current filter.
+* Ditto for thread below.
+*/
+ do_zoom_dso(browser, actions);
}
- ui_helpline__pop();
- hist_browser__reset(browser);
+ if (top == >hists->thread_filter)
+ do_zoom_thread(browser, actions);
continue;
}
case K_ESC:
--
2.3.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 9/10] perf tools: Introduce pstack_peek()
The pstack_peek() is to get the topmost entry without removing it.
Signed-off-by: Namhyung Kim
---
I also pushed to perf/tui-cleanup-v4.
tools/perf/util/pstack.c | 7 +++
tools/perf/util/pstack.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/pstack.c b/tools/perf/util/pstack.c
index a126e6cc6e73..b234a6e3d0d4 100644
--- a/tools/perf/util/pstack.c
+++ b/tools/perf/util/pstack.c
@@ -74,3 +74,10 @@ void *pstack__pop(struct pstack *pstack)
pstack->entries[pstack->top] = NULL;
return ret;
}
+
+void *pstack__peek(struct pstack *pstack)
+{
+ if (pstack->top == 0)
+ return NULL;
+ return pstack->entries[pstack->top - 1];
+}
diff --git a/tools/perf/util/pstack.h b/tools/perf/util/pstack.h
index c3cb6584d527..ded7f2e36624 100644
--- a/tools/perf/util/pstack.h
+++ b/tools/perf/util/pstack.h
@@ -10,5 +10,6 @@ bool pstack__empty(const struct pstack *pstack);
void pstack__remove(struct pstack *pstack, void *key);
void pstack__push(struct pstack *pstack, void *key);
void *pstack__pop(struct pstack *pstack);
+void *pstack__peek(struct pstack *pstack);
#endif /* _PERF_PSTACK_ */
--
2.3.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: [v6] kvm/fpu: Enable fully eager restore kvm FPU
H. Peter Anvin wrote on 2015-04-24: > On 04/23/2015 08:28 AM, Dave Hansen wrote: >> On 04/23/2015 02:13 PM, Liang Li wrote: >>> When compiling kernel on westmere, the performance of eager FPU is >>> about 0.4% faster than lazy FPU. >> >> Do you have an theory why this is? What does the regression come from? >> > > This is interesting since previous measurements on KVM have had the > exact opposite results. I think we need to understand this a lot more. What I can tell is that vmexit is heavy. So it is reasonable to see the improvement under some cases, especially kernel is using eager FPU now which means each schedule may trigger a vmexit. > > -hpa > Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broadcom 43340 module on iMX6DL
Btw, where I could get a copy of the latest driver?. Regards, John On Thu, Apr 23, 2015 at 5:59 PM, John Tobias wrote: > Hi John, > > Is it possible to have a copy of the firmware for 43340?. > > Regards, > > John > > On Thu, Apr 23, 2015 at 5:57 PM, John Stultz wrote: >> On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel >> wrote: >>> By the name of the file I suspected you did. Personally, I verified the >>> firmware works on 43341. John Stultz tested both 43340 and 43341 with this >>> firmware. >> >> Minor correction here, I only tested on 43341 hardware. The confusion >> might be that the firmware I originally had access to claimed it was >> 43340. >> >> thanks >> -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: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary
On 04/23/2015 03:55 PM, Andy Lutomirski wrote: > On Thu, Apr 23, 2015 at 3:52 PM, H. Peter Anvin wrote: >> On 04/23/2015 03:38 PM, Andy Lutomirski wrote: Because there are way more sysrets than context switches, and Linux is particularly sensitive to system call latency, by design. >>> >> >> Just to clarify: why would Linux be more sensitive to system call by >> design? It enables much simpler APIs and avoids hacks like sending down >> a syscall task list (which was genuinely proposed at one point.) If >> kernel entry/exit is too expensive, then the APIs get more complex >> because they *have* to do everything in the smallest number of system calls. >> > > It's a matter of the ratio, right? One cycle of syscall overhead > saved is worth some number of context switch cycles added, and the > ratio probably varies by workload. > Correct. For workloads which do *no* system calls it is kind of "special". > If we do syscall, two context switches, and sysret, then we wouldn't > have been better off fixing it on sysret. But maybe most workloads > still prefer the fixup on context switch. > There is also a matter of latency, which tends to be more critical for syscall. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 6/8] extcon: arizona: Add support for WM8998 and WM1814
On 04/23/2015 11:15 PM, Richard Fitzgerald wrote: > On Wed, Apr 22, 2015 at 07:20:09PM +0900, Chanwoo Choi wrote: >> On 04/22/2015 06:19 PM, Richard Fitzgerald wrote: >>> On Wed, Apr 22, 2015 at 02:53:42PM +0900, Chanwoo Choi wrote: Hi Richard, > @@ -1176,6 +1182,11 @@ static int arizona_extcon_probe(struct > platform_device *pdev) > break; > } > break; > + case WM8998: > + case WM1814: > + info->micd_clamp = true; > + info->hpdet_ip = 2; What is meaning of '2'? I prefer to use the definition for '2'. >>> >>> '2' is the version number of the hpdet ip block in silicon. We're already >>> using >>> it as a raw number '0', '1' or '2' all over extcon-arizona.c so changing it >>> here >>> would mean making other patches to the file that aren't really part of >>> adding >>> WM8998 support, so I'd prefer not to change that as a side-effect of adding >>> WM8998. >> >> I think that just you can define following definitions and use >> HPDET_IP_VER_V2 instead of '2'. >> >> #define HPDET_IP_VER_V0 0 >> #define HPDET_IP_VER_V1 1 >> #define HPDET_IP_VER_V2 2 >> > > Can we deal with that as a separate patch from this series? Like I said, > the code already uses '0' '1' and '2' for the existing codecs so making a > change to use #define means patching the code for the other codecs. That > is not part of adding WM8998 support and I don't like patches that make > unexpected extra side-effect changes that are not relevant to the actual > functionality being added by the patch. It's specially annoying when > cherry-picking or reverting those patches if they included some extra > code change. > > If we can get this series submitted I can look at making a later patch > to improve readbility, but since this really is just a version number I > think it would be enough to rename the variable to hpdet_ip_version rather > than effectively doing #define TWO 2 OK. I agree that rename the variable name (hpdet_ip_version) or add the definitions for version on later patch. Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Broadcom 43340 module on iMX6DL
Hi John, Is it possible to have a copy of the firmware for 43340?. Regards, John On Thu, Apr 23, 2015 at 5:57 PM, John Stultz wrote: > On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote: >> By the name of the file I suspected you did. Personally, I verified the >> firmware works on 43341. John Stultz tested both 43340 and 43341 with this >> firmware. > > Minor correction here, I only tested on 43341 hardware. The confusion > might be that the firmware I originally had access to claimed it was > 43340. > > thanks > -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: Broadcom 43340 module on iMX6DL
On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote: > By the name of the file I suspected you did. Personally, I verified the > firmware works on 43341. John Stultz tested both 43340 and 43341 with this > firmware. Minor correction here, I only tested on 43341 hardware. The confusion might be that the firmware I originally had access to claimed it was 43340. thanks -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: git pull] drm for v4.1-rc1
On Thu, Apr 23, 2015 at 5:30 PM, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
>> Hmm. The odd Intel PCI resource mess is back.
>>
>> Or maybe it never went away.
>>
>> I get these when suspending. Things *work*, but it's really spamming
>> my logs a fair bit:
>>
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> pci_bus :01: Allocating resources
>> pci_bus :02: Allocating resources
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>
>> That resource is complete garbage. "flags 0x2" is not even a valid
>> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
>> that is valid, then it should also have have had the IORESOURCE_MEM
>> bit, and it doesn't.
>
> Your i915 does not have a ROM BAR in hardware. If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
> shadow ROM image at 0xC. Is there a shadow image even if the
> device itself doesn't have a ROM BAR?
Very likely yes. With integrated APUs and mobile dGPUs, the vbios
image is often stored as part of the system rom rather than as a
dedicated rom for the GPU. The vbios image is then copied to the
shadow location during sbios init to provide OS access to the rom.
Alex
>
> We could fabricate a resource even if the BAR doesn't exist, e.g.,
> "flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
> would be ugly and error-prone in other places that use the ROM.
>
> Matthew added dev->rom for ROM images supplied by the platform
> (84c1b80e3263 ("PCI: Add support for non-BAR ROMs")). A shadow
> image seems like a similar thing. I think it would be cleaner to get
> rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
> 0xC" if there's a shadow image, e.g.:
>
> int pcibios_add_device(struct pci_dev *dev)
> {
> if (dev-is-default-vga-device) {
> dev->rom = 0xC;
> dev->romlen = 0x2;
> }
>
> pa_data = boot_params.hdr.setup_data;
> while (pa_data) {
> ...
> if (data->type == SETUP_PCI) {
> rom = (struct pci_setup_rom *)data;
>
> if (dev-is-rom-dev) {
> dev->rom = ...
> dev->romlen = rom->pcilen;
> }
> }
> }
>
> But the rules for figuring out which image to use seem ...
> complicated.
>
> Bjorn
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] watchdog: Use a reference cycle counter to avoid scaling issues
> We can just detect the deviation in the callback itself: > >u64 now = ktime_get_mono_fast_ns(); > >if (now - __this_cpu_read(nmi_timestamp) < period) > return; > >__this_cpu_write(nmi_timestamp, now); > > It's that simple. It's a simple short term hac^wsolution. But if we had a (hypothetical) system with let's say 10*TSC max you may end up with quite a few false ticks, as in unnecessary interrupts. With 100*TSC it would be really bad. There were systems in the past that ran TSC at a much slower frequency, such as the early AMD Barcelona systems. So the problem may eventually come back if not solved properly. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input - mt: Fix input_mt_get_slot_by_key
On Thu, Apr 23, 2015 at 11:47:09AM -0700, Dmitry Torokhov wrote: > On Thu, Apr 23, 2015 at 02:38:27PM -0400, Benjamin Tissoires wrote: > > On Apr 23 2015 or thereabouts, Dmitry Torokhov wrote: > > > On Thu, Apr 23, 2015 at 07:10:55PM +0200, Henrik Rydberg wrote: > > > > > "Creation, replacement and destruction of contacts is achieved by > > > > > modifying the ABS_MT_TRACKING_ID of the associated slot. A > > > > > non-negative tracking id is interpreted as a contact, and the value -1 > > > > > denotes an unused slot. A tracking id not previously present is > > > > > considered new, and a tracking id no longer present is considered > > > > > removed." > > > > > > > > > > If some userspace is confused with missing -1 tracking ID for that > > > > > slot, that userspace should be fixed. > > > > > > > > I agree. Some userland applications work with add/remove out of > > > > convenience, and > > > > cannot handle the more compressed notation the kernel slot handling > > > > allows. > > > > Fixing those applications will be a good thing. > > > > > > > > Unfortunately the patch already appeared in Linus' tree... > > > > > > It's in 4.1-rc0 so we can just revert it. > > > > > > > Before we call for a revert, I'd like to hear Peter thoughts about it, > > as he is the main user of the slotted protocol. > > > > Also, Dmitry, can you check if the ChromeOS driver and (or) the android > > one would need to be adapted? My guess is that none of these drivers are > > able to handle a silent closing of a slot > > I will, at least for Chrome. But if it is broken I'll simply open a big > to fix it ;) > > > and the easiest solution might > > be to simply change the documentation if in fact nobody uses the > > compressed notation (which removes just one ABS_SLOT event within the > > frame, so not sure we can call it compressed BTW). > > No, it is more that that I think. Wouldn't we need to allocate memory > for 2*n slots to actually reliably track all contacts if they all happen > to get released and put back onto the surface in different place very > very quickly if we insist on sending tracking id -1 for previously used > slots? can't you just slot in an extra event that contains only the ABS_MT_TRACKING_ID -1 for the needed slots, followed by an SYN_REPORT and whatever BTN_TOOL_* updates are needed? You don't need extra slots here, you're just putting one extra event in the queue before handling the new touches as usual. thing is: I've always assumed that a touch is terminated by a -1 event and this hasn't been a problem until very recently. so anything I've ever touched will be broken if we start switching tracking IDs directly. That includes xorg input, libinput and anything that uses libevdev. sorry. if the kernel switches from one tracking ID to another directly, libevdev will actually discard the new tracking ID. http://cgit.freedesktop.org/libevdev/tree/libevdev/libevdev.c#n968 (sorry again) aside from the warning, it's safe to switch directly though, there shouldn't be any side-effects. as for fixing this: I can add something to libevdev to allow it but I'll also need to fix up every caller to handle this sequence then, they all rely on the -1. so some stuff will simply break. plus we still have synaptics up to 1.7.x and evdev up to 2.8.x that are pre-libevdev. for other event processing it's tricky as well. if you go from two touches to two new touches you need to send out a BTN_TOOL_DOUBLETAP 0, then 1. if not, a legacy process missed the event completely (synaptics would suffer from that). likewise, without the BTN_TOUCH going to 0 for one frame you'll get coordinate jumps on the pointer emulation. having the tracking ID go -1 and then to a real one in the same frame makes this even worse, because now even the MT-capable processes need to attach flags to each touch whether it intermediately terminated or not. The event ordering is not guaranteed, so we don't know until the SYN_REPORT whether we switched from 2 fingers to 1, or 2 fingers to 2 fingers. or possibly three fingers if BTN_TOOL_TRIPLETAP is set which we won't know until the end. That has to be fixed in every caller. and it changes the evdev protocol from "you have the state at SYN_REPORT" to "you need to keep track of some state changes within the frame". that's no good. so summary: switching directly between IDs is doable but requires userspace fixes everywhere. terminating and restarting a contact within the same frame is going to be nasty, let's not do that please. best solution: the kernel inserts an additional event to terminate all restarted contacts before starting the new ones as normal in the subsequent frame. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Broadcom 43340 module on iMX6DL
Hello Guys,
I have a follow up questions:
When the I power up the brcm44340 without loading the driver, the
sdhci-esdhc-imx host controller configured it with the following info
(cat /sys/kernel/debug/mmc0/ios):
clock: 5000 Hz
actual clock: 4950 Hz
vdd: 17 (2.9 ~ 3.0 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
Then, when I load the bcmdhd driver, the driver changed the clock to:
clock: 40 Hz
actual clock: 386718 Hz
vdd: 17 (2.9 ~ 3.0 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 0 (1 bits)
timing spec: 0 (legacy)
signal voltage: 0 (3.30 V)
Trace from sdhci-esdhc-imx:
MMC0: sdhci-esdhc-imx: desired SD clock: 40, actual: 386718
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 40, actual: 386718
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 40, actual: 386718
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 40, actual: 386718
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 40, actual: 386718
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 30, actual: 281250
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 30, actual: 281250
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 30, actual: 281250
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 30, actual: 281250
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 30, actual: 281250
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: change pinctrl state for uhs 0
MMC0: sdhci-esdhc-imx: desired SD clock: 20, actual: 193359
Does the driver need to change the clock when loading the firmware?.
Is it possible to tell to the driver to skip changing the clock?.
Or any work around for the problem?.
Note: attached is a verbose logs of the driver.
Regards,
John
On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote:
> + John Stultz
>
>
> On 04/23/15 20:44, John Tobias wrote:
>>
>> Thanks Dmitry for the info.
>>
>> Arend:
>>
>> Yes, it's an android... Here's the info:
>>
>> 00060e80 de 02 f0 18 8c 00 e8 5e 8f 00 37 a3 00 e0 5e 8a
>> |...^..7...^.|
>> 00060e90 f4 77 a2 00 02 de 02 f0 00 00 01 bc 60 03 00 07
>> |.w..`...|
>> 00060ea0 aa 01 bc 60 03 00 07 ab 01 bc 60 03 00 07 b7 01
>> |...`..`.|
>> 00060eb0 bc 60 13 08 17 a1 00 02 5e 02 f0 01 28 00 b0 40
>> |.`..^...(..@|
>> 00060ec0 67 00 17 a3 01 80 60 02 03 37 a2 00 02 5e 02 f0
>> |g.`..7...^..|
>> 00060ed0 01 2c 00 b0 5e 8f 00 17 a2 00 02 5e 02 f0 01 2c
>> |.,..^..^...,|
>> 00060ee0 00 02 de 02 f0 00 00 01 bc 60 63 00 10 7b 00 b0
>> |.`c..{..|
>> 00060ef0 5e 8b 00 10 7a 01 ac 60 7e f4 30 75 02 87 41 d7
>> |^...z..`~.0u..A.|
>> 00060f00 00 18 9c 00 02 de 02 f0 00 00 01 bc 60 63 00 10
>> |`c..|
>> 00060f10 7b 00 b0 5e 8b 00 10 7a 01 ac 60 be f4 30 75 02
>> |{..^...z..`..0u.|
>> 00060f20 87 41 d7 00 18 a1 00 02 de 02 f0 00 00 00 00 00
>> |.A..|
>> 00060f30 00 00 00 00 7c ac 00 00 2d cb a7 58 06 0a be 31
>> ||...-..X...1|
>> 00060f40 b1 8d a0 53 00 5b 07 49 45 13 20 4e 7d 7e 47 28 |...S.[.IE.
>> N}~G(|
>> 00060f50 08 7c 77 d2 bc 44 87 13 01 bd 32 08 01 00 34 33
>> |.|w..D2...43|
>> 00060f60 33 34 31 62 30 2d 72 6f 6d 6c 2f 73 64 69 6f 2d
>> |341b0-roml/sdio-|
>> 00060f70 61 67 2d 70 6e 6f 2d 70 32 70 2d 63 63 78 2d 65
>> |ag-pno-p2p-ccx-e|
>> 00060f80 78 74 73 75 70 2d 70 72 6f 70 74 78 73 74 61 74
>> |xtsup-proptxstat|
>> 00060f90 75 73 2d 64 6d 61 74 78 72 63 2d 72 78 6f 76 2d
>> |us-dmatxrc-rxov-|
>> 00060fa0 70 6b 74 66 69 6c 74 65 72 2d 6b 65 65 70 61 6c
>> |pktfilter-keepal|
>> 00060fb0 69 76 65 2d 61 6f 65 2d 76 73 64 62 2d 73 72 2d
>> |ive-aoe-vsdb-sr-|
>> 00060fc0 77 61 70 69 2d 77 6c 31 31 64 2d 61 75 74 6f 61
>> |wapi-wl11d-autoa|
>> 00060fd0 62 6e 2d 6c 70 63 2d 70 63 6c 6f 73 65 2d 70 32
>> |bn-lpc-pclose-p2|
>> 00060fe0 70 6f 2d 77 6c 31 31 75 20 56 65 72 73 69 6f 6e |po-wl11u
>> Version|
>> 00060ff0 3a 20 36 2e 31 30 2e 31 39 30 2e 34 39 20 43 52 |: 6.10.190.49
>> CR|
>> 00061000 43 3a 20 61 37 35 38 33 34 64 32 20 44 61 74 65 |C: a75834d2
>> Date|
>> 00061010 3a 20 54 75 65 20 32 30 31 34 2d 30 36 2d 31 37 |: Tue
>> 2014-06-17|
>> 00061020 20 31 31 3a 34 39 3a 32 31 20 50 44 54 20 46 57 | 11:49:21 PDT
>> FW|
>> 00061030 49 44 20 30 31 2d 38 37 34 34 62 63 64 32 0a 00 |ID
>> 01-8744bcd2..|
>> 00061040 e2 00
Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers
On Sat, Apr 18, 2015 at 9:16 AM, Kevin Cernekee wrote: >>> + case SND_SOC_BIAS_OFF: >>> + /* Note that this kills I2C accesses. */ >>> + assert_pdn = 1; >> >> No, the GPIO set associated with it kills I2C access. I'd also expect >> to see the regmap being marked cache only before we do this and a resync >> of the register map when we power back up (assuming that is actually a >> power down). > > Hmm, not sure if this actually resets the registers back to power-on > defaults, but I'll check. Hi Mark, I have reworked the driver to do the following: - set appropriate regmap default values on probe - enable idle_bias_off - use regcache_cache_only() to prevent accesses to I2C when in SND_SOC_BIAS_OFF state (pdn asserted) - use regcache_sync() when transitioning from SND_SOC_BIAS_OFF -> SND_SOC_BIAS_STANDBY This is mostly working OK, but regcache_sync() assumes that the hardware registers have been reset back to the default values. The "pdn" GPIO doesn't actually reset the state of the tas571x; it just makes I2C inaccessible and inhibits audio output. So if the factory default for mute is 0, corner cases like this fail: - enter SND_SOC_BIAS_ON (e.g. play a wav file) - set mute to 1 - enter SND_SOC_BIAS_OFF (e.g. playback ends) - set mute to 0 - re-enter SND_SOC_BIAS_ON - regcache_sync() incorrectly assumes that the hardware register is already 0, but in fact it needs to be refreshed from the cache Aside from unnecessarily pulsing the reset GPIO when transitioning back from SND_SOC_BIAS_OFF or overriding regcache_default_sync(), can you think of a way to work around this? 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 v6 1/2] Devicetree: Add pl353 smc controller devicetree binding information
Hi Josh, > -Original Message- > From: Josh Cartwright [mailto:jo...@ni.com] > Sent: Friday, April 24, 2015 1:21 AM > To: Punnaiah Choudary Kalluri > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; r...@landley.net; > Michal Simek; grant.lik...@linaro.org; gre...@linuxfoundation.org; > ja...@lakedaemon.net; ezequiel.gar...@free-electrons.com; > a...@arndb.de; dw...@infradead.org; computersforpe...@gmail.com; > artem.bityuts...@linux.intel.com; jussi.kivili...@iki.fi; > acour...@nvidia.com; ivan.khoronz...@ti.com; jo...@logfs.org; > devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org; kpc...@gmail.com; > kalluripunnaiahchoud...@gmail.com; Punnaiah Choudary Kalluri > Subject: Re: [PATCH v6 1/2] Devicetree: Add pl353 smc controller devicetree > binding information > > Hey Punnaiah- > > A few nitpicks here, in case you'll be spinning up a new version of your > patchset. > > On Mon, Apr 13, 2015 at 09:41:51PM +0530, Punnaiah Choudary Kalluri wrote: > > Add pl353 static memory controller devicetree binding information. > > > > Signed-off-by: Punnaiah Choudary Kalluri > [..] > > @@ -0,0 +1,37 @@ > > +Device tree bindings for ARM PL353 static memory controller > > + > > +PL353 static memory controller supports two kinds of memory > > +interfaces. i.e NAND and SRAM/NOR interfaces. > > +The actual devices are instantiated from the child nodes of pl353 smc > node. > > + > > +Required properties: > > +- compatible : Should be "arm,pl353-smc-r2p1" > > +- reg : Controller registers map and length. > > +- clock-names : List of input clock names - "memclk", "aclk" > > + (See clock bindings for details). > > +- clocks : Clock phandles (see clock bindings for details). > > Technically not clock phandles, but clock specifiers. > > > +- address-cells: Address cells, must be 1. > > +- size-cells : Size cells. Must be 1. > > These should have the leading '#' as in '#address-cells' and > '#size-cells'. Thanks for the review. I will take care of them new version Regards, Punnaiah > > 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] mm: soft-offline: fix num_poisoned_pages counting on concurrent events
On 04/20/2015 11:18 PM, Naoya Horiguchi wrote:
> If multiple soft offline events hit one free page/hugepage concurrently,
> soft_offline_page() can handle the free page/hugepage multiple times,
> which makes num_poisoned_pages counter increased more than once.
> This patch fixes this wrong counting by checking TestSetPageHWPoison for
> normal papes and by checking the return value of
> dequeue_hwpoisoned_huge_page()
> for hugepages.
>
> Signed-off-by: Naoya Horiguchi
Acked-by: Dean Nelson
> Cc: sta...@vger.kernel.org # v3.14+
> ---
> # This problem might happen before 3.14, but it's rare and non-critical,
> # so I want this patch to be backported to stable trees only if the patch
> # cleanly applies (i.e. v3.14+).
> ---
> mm/memory-failure.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git v4.0.orig/mm/memory-failure.c v4.0/mm/memory-failure.c
> index 2cc1d578144b..72a5224c8084 100644
> --- v4.0.orig/mm/memory-failure.c
> +++ v4.0/mm/memory-failure.c
> @@ -1721,12 +1721,12 @@ int soft_offline_page(struct page *page, int flags)
> } else if (ret == 0) { /* for free pages */
> if (PageHuge(page)) {
> set_page_hwpoison_huge_page(hpage);
> - dequeue_hwpoisoned_huge_page(hpage);
> - atomic_long_add(1 << compound_order(hpage),
> + if (!dequeue_hwpoisoned_huge_page(hpage))
> + atomic_long_add(1 << compound_order(hpage),
> _poisoned_pages);
> } else {
> - SetPageHWPoison(page);
> - atomic_long_inc(_poisoned_pages);
> + if (!TestSetPageHWPoison(page))
> + atomic_long_inc(_poisoned_pages);
> }
> }
> unset_migratetype_isolate(page, MIGRATE_MOVABLE);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm/hwpoison-inject: check PageLRU of hpage
On 04/16/2015 09:08 PM, Naoya Horiguchi wrote: > Hwpoison injector checks PageLRU of the raw target page to find out whether > the page is an appropriate target, but current code now filters out thp tail > pages, which prevents us from testing for such cases via this interface. > So let's check hpage instead of p. > > Signed-off-by: Naoya Horiguchi Acked-by: Dean Nelson > --- > mm/hwpoison-inject.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git v4.0.orig/mm/hwpoison-inject.c v4.0/mm/hwpoison-inject.c > index 2b3f933e3282..4ca5fe0042e1 100644 > --- v4.0.orig/mm/hwpoison-inject.c > +++ v4.0/mm/hwpoison-inject.c > @@ -34,12 +34,12 @@ static int hwpoison_inject(void *data, u64 val) > if (!hwpoison_filter_enable) > goto inject; > > - if (!PageLRU(p) && !PageHuge(p)) > - shake_page(p, 0); > + if (!PageLRU(hpage) && !PageHuge(p)) > + shake_page(hpage, 0); > /* >* This implies unable to support non-LRU pages. >*/ > - if (!PageLRU(p) && !PageHuge(p)) > + if (!PageLRU(hpage) && !PageHuge(p)) > goto put_out; > > /* > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm/hwpoison-inject: fix refcounting in no-injection case
On 04/16/2015 09:08 PM, Naoya Horiguchi wrote:
> Hwpoison injection via debugfs:hwpoison/corrupt-pfn takes a refcount of
> the target page. But current code doesn't release it if the target page
> is not supposed to be injected, which results in memory leak.
> This patch simply adds the refcount releasing code.
>
> Signed-off-by: Naoya Horiguchi
Acked-by: Dean Nelson
> ---
> mm/hwpoison-inject.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git v4.0.orig/mm/hwpoison-inject.c v4.0/mm/hwpoison-inject.c
> index 329caf56df22..2b3f933e3282 100644
> --- v4.0.orig/mm/hwpoison-inject.c
> +++ v4.0/mm/hwpoison-inject.c
> @@ -40,7 +40,7 @@ static int hwpoison_inject(void *data, u64 val)
>* This implies unable to support non-LRU pages.
>*/
> if (!PageLRU(p) && !PageHuge(p))
> - return 0;
> + goto put_out;
>
> /*
>* do a racy check with elevated page count, to make sure PG_hwpoison
> @@ -52,11 +52,14 @@ static int hwpoison_inject(void *data, u64 val)
> err = hwpoison_filter(hpage);
> unlock_page(hpage);
> if (err)
> - return 0;
> + goto put_out;
>
> inject:
> pr_info("Injecting memory failure at pfn %#lx\n", pfn);
> return memory_failure(pfn, 18, MF_COUNT_INCREASED);
> +put_out:
> + put_page(hpage);
> + return 0;
> }
>
> static int hwpoison_unpoison(void *data, u64 val)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: image: mdc800: fixed various style issues
Fixed several style issues with: comments, function perenthesis,
indentation, and conditional braces
Signed-off-by: Jason Eastman
---
drivers/usb/image/mdc800.c | 769 +++-
1 file changed, 336 insertions(+), 433 deletions(-)
diff --git a/drivers/usb/image/mdc800.c b/drivers/usb/image/mdc800.c
index 5cf2633..c9b9ec0 100644
--- a/drivers/usb/image/mdc800.c
+++ b/drivers/usb/image/mdc800.c
@@ -29,19 +29,19 @@
* mknod /dev/mustek c 180 32
*
* The driver supports only one camera.
- *
+ *
* Fix: mdc800 used sleep_on and slept with io_lock held.
* Converted sleep_on to waitqueues with schedule_timeout and made io_lock
* a semaphore from a spinlock.
* by Oliver Neukum
* (02/12/2001)
- *
+ *
* Identify version on module load.
* (08/04/2001) gb
*
* version 0.7.5
* Fixed potential SMP races with Spinlocks.
- * Thanks to Oliver Neukum who
+ * Thanks to Oliver Neukum who
* noticed the race conditions.
* (30/10/2000)
*
@@ -108,7 +108,7 @@
#define DRIVER_DESC "USB Driver for Mustek MDC800 Digital Camera"
/* Vendor and Product Information */
-#define MDC800_VENDOR_ID 0x055f
+#define MDC800_VENDOR_ID 0x055f
#define MDC800_PRODUCT_ID 0xa800
/* Timeouts (msec) */
@@ -116,7 +116,7 @@
#define TO_DOWNLOAD_GET_BUSY 1500
#define TO_WRITE_GET_READY 1000
#define TO_DEFAULT_COMMAND 5000
-#define TO_READ_FROM_IRQ TO_DEFAULT_COMMAND
+#define TO_READ_FROM_IRQ TO_DEFAULT_COMMAND
#define TO_GET_READY TO_DEFAULT_COMMAND
/* Minor Number of the device (create with mknod /dev/mustek c 180 32) */
@@ -134,124 +134,119 @@ typedef enum {
/* Data for the driver */
-struct mdc800_data
-{
- struct usb_device * dev;// Device Data
- mdc800_statestate;
+struct mdc800_data {
+ struct usb_device *dev; /* Device Data */
+ mdc800_statestate;
unsigned intendpoint [4];
- struct urb *irq_urb;
+ struct urb *irq_urb;
wait_queue_head_t irq_wait;
int irq_woken;
- char* irq_urb_buffer;
+ char*irq_urb_buffer;
- int camera_busy; // is camera busy ?
- int camera_request_ready; // Status to synchronize
with irq
- charcamera_response [8]; // last Bytes send after
busy
+ int camera_busy; /* is camera busy ? */
+ int camera_request_ready; /* Status to synchronize
with irq */
+ charcamera_response[8]; /* last Bytes send after
busy */
- struct urb *write_urb;
- char* write_urb_buffer;
+ struct urb *write_urb;
+ char*write_urb_buffer;
wait_queue_head_t write_wait;
int written;
- struct urb *download_urb;
- char* download_urb_buffer;
+ struct urb *download_urb;
+ char*download_urb_buffer;
wait_queue_head_t download_wait;
int downloaded;
- int download_left; // Bytes left to
download ?
+ int download_left; /* Bytes left to
download ? */
/* Device Data */
- charout [64]; // Answer Buffer
- int out_ptr;// Index to the first not
readen byte
- int out_count; // Bytes in the buffer
+ charout[64];/* Answer Buffer */
+ int out_ptr;/* Index to the first not
readen byte */
+ int out_count; /* Bytes in the buffer */
- int open; // Camera device open ?
- struct mutexio_lock;// IO -lock
+ int open; /* Camera device open ? */
+ struct mutexio_lock;/* IO -lock */
- charin [8]; // Command Input Buffer
- int in_count;
+ charin[8]; /* Command Input Buffer */
+ int in_count;
- int pic_index; // Cache for the Imagesize (-1
for nothing cached )
+ int pic_index; /* Cache for the Imagesize (-1
for nothing cached ) */
int pic_len;
int minor;
};
/* Specification of the Endpoints */
-static struct usb_endpoint_descriptor mdc800_ed [4] =
-{
- {
- .bLength
4.0-rc1 perf build error "builtin-kmem.c:322: error: declaration of ‘stat’ shadows a global declaration"
Hi. 4.0-rc1 commit 0d68bc92c48167130b61b449f08be27dc862dba2 "perf kmem: Analyze page allocator events also" introduced a build error with older toolchains. For example, this build errors occurs on CentOS 6. CC builtin-kmem.o cc1: warnings being treated as errors builtin-kmem.c: In function ‘search_page_alloc_stat’: builtin-kmem.c:322: error: declaration of ‘stat’ shadows a global declaration /usr/include/sys/stat.h:455: error: shadowed declaration is here builtin-kmem.c: In function ‘perf_evsel__process_page_alloc_event’: builtin-kmem.c:378: error: declaration of ‘stat’ shadows a global declaration /usr/include/sys/stat.h:455: error: shadowed declaration is here builtin-kmem.c: In function ‘perf_evsel__process_page_free_event’: builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global declaration /usr/include/sys/stat.h:455: error: shadowed declaration is here Cheers, Vinson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
On Thu, Apr 23, 2015 at 6:19 PM, Michal Simek wrote: > On 04/16/2015 03:56 PM, Punnaiah Choudary Kalluri wrote: >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> drivers/mtd/nand/Kconfig |7 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/arasan_nfc.c | 861 >> + >> 3 files changed, 869 insertions(+), 0 deletions(-) >> create mode 100644 drivers/mtd/nand/arasan_nfc.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 5897d8d..64e497c 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -530,4 +530,11 @@ config MTD_NAND_HISI504 >> help >> Enables support for NAND controller on Hisilicon SoC Hip04. >> >> +config MTD_NAND_ARASAN >> + tristate "Support for Arasan Nand Flash controller" >> + depends on MTD_NAND >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 582bbd05..fd863ea 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o >> obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ >> obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o >> obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o >> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nfc.o >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c >> new file mode 100644 >> index 000..a4b407b >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nfc.c >> @@ -0,0 +1,861 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * 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; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > > For !CONFIG_OF_MTD here should be also. Kbuild system just reported this > problem. > > #include > > For the rest > Tested-by: Michal Simek Ok. I will check and update this. Thanks Punnaiah > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] mtd: nand_bbt: drop unnecessary header
On 23 April 2015 at 15:47, Rafał Miłecki wrote: > On 22 April 2015 at 19:50, Brian Norris > wrote: > > On Thu, Apr 16, 2015 at 02:09:41AM +, Peter Pan 潘栋 > (peterpandong) wrote: > >> > >> Signed-off-by: Brian Norris > >> Signed-off-by: Peter Pan > > > > Why are you just resending my patches? You could Ack/Reviewed-by/etc. > > instead... > > > > http://patchwork.ozlabs.org/patch/444604/ > > That was fishy to me too, thanks for clarifying it Brian. > > Also, if you *really* need to submit somebody's patch, you *should* > use From to point the author to git. Hi Brain and Rafał, I am really sorry for this. It is my mistake. I just start sending patch to community recently. If I do something improper, please tell me. I will resend Brain's and my patch with the right comment, but please look through this patchset if you can. Sorry for bringing troubles to you again. Thanks Peter Pan
Re: [PATCH] exit,stats: /* obey this comment */
On 04/23/2015 05:47 PM, Andrew Morton wrote:
> On Thu, 23 Apr 2015 17:17:59 -0400 Rik van Riel wrote:
>
>> There is a helpful comment in do_exit() that states we sync the
>> mm's RSS info before statistics gathering.
>>
>> The function that does the statistics gathering is called right
>> above that comment.
>>
>> Change the code to obey the comment.
>>
>> ...
>>
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -711,10 +711,10 @@ void do_exit(long code)
>> current->comm, task_pid_nr(current),
>> preempt_count());
>>
>> -acct_update_integrals(tsk);
>> /* sync mm's RSS info before statistics gathering */
>> if (tsk->mm)
>> sync_mm_rss(tsk->mm);
>> +acct_update_integrals(tsk);
>> group_dead = atomic_dec_and_test(>signal->live);
>> if (group_dead) {
>> hrtimer_cancel(>signal->real_timer);
>
> I can't actually find anywhere where these counters are used in the
> accounting code.
Don't the get reported to userspace in things like this?
$ /usr/bin/time ls /dev
...
0.00user 0.00system 0:00.00elapsed 33%CPU (0avgtext+0avgdata
2652maxresident)k
0inputs+0outputs (0major+135minor)pagefaults 0swaps
Though admittedly this thing only reports maxresident...
I think there is some tool that reports the avg resident rss,
but I cannot remember what it is.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the blackfin tree with Linus' tree
Hi all,
Today's linux-next merge of the blackfin tree got a conflict in
arch/blackfin/mach-common/smp.c between commit a17b4b7487eb ("blackfin:
Use common outgoing-CPU-notification code") from Linus' tree and commit
ca2b83264d99 ("blackfin: make timeout HZ independent") from the
blackfin tree.
I fixed it up (the former supercedes the latter, I think) and can carry
the fix as necessary (no action is required).
P.S. Steven, you committed that blackfin tree patch, but did not add you
Signed-off-by ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgplEI41U8kH_.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/2] checkpatch: suggest using eth_zero_addr() and eth_broadcast_addr()
On Thu, 2015-04-23 at 16:54 -0700, Joe Perches wrote: > On Thu, 2015-04-23 at 21:53 +0200, Mateusz Kulikowski wrote: > > I noticed funny behavior about $stat matches - > > it reports the same error several times (including as "scope" whole file) > > Is it feature or "feature" or I missed something? > > You have to make sure the first character of $stat is a + > > if ($stat =~ /\+(?:.*)\bmem Make that if ($stat =~ /^\+(?:.*)\bmem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RESEND PATCH 5/8] mfd: cros-ec: Support multiple EC in a system
This patch needs https://chromium-review.googlesource.com/217297:
/dev/cros_ec0 was not a good idea, because it is difficult to know
what it represents.
On Mon, Apr 6, 2015 at 9:15 AM, Javier Martinez Canillas
wrote:
> From: Gwendal Grignou
>
> Chromebooks can have more than one Embedded Controller so the
> cros_ec device id has to be incremented for each EC registered.
>
> Add code to handle multiple EC. First ec found is cros-ec0,
cros_ec0
> second cros-ec1 and so on.
cros_ec1
>
> Signed-off-by: Gwendal Grignou
> Reviewed-by: Dmitry Torokhov
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/mfd/cros_ec.c | 7 ++-
> drivers/platform/chrome/cros_ec_dev.c | 4 ++--
> include/linux/mfd/cros_ec.h | 2 ++
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index c532dbca7404..70f6e55a096e 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -28,6 +28,8 @@
>
> #define EC_COMMAND_RETRIES 50
>
> +static int dev_id;
> +
> int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>struct cros_ec_command *msg)
> {
> @@ -130,6 +132,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> struct device *dev = ec_dev->dev;
> int err = 0;
>
> + ec_dev->id = dev_id;
> +
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
> if (!ec_dev->din)
> @@ -143,7 +147,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>
> mutex_init(_dev->lock);
>
> - err = mfd_add_devices(dev, 0, cros_devs,
> + err = mfd_add_devices(dev, ec_dev->id, cros_devs,
> ARRAY_SIZE(cros_devs),
> NULL, ec_dev->irq, NULL);
> if (err) {
> @@ -159,6 +163,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> return err;
> }
> #endif
> + dev_id += ARRAY_SIZE(cros_devs);
>
> dev_info(dev, "Chrome EC device registered\n");
>
> diff --git a/drivers/platform/chrome/cros_ec_dev.c
> b/drivers/platform/chrome/cros_ec_dev.c
> index e7e50f18097f..7173f0ea6ae5 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -191,7 +191,7 @@ static int ec_device_probe(struct platform_device *pdev)
> {
> struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
> int retval = -ENOTTY;
> - dev_t devno = MKDEV(ec_major, 0);
> + dev_t devno = MKDEV(ec_major, ec->id);
>
> /* Instantiate it (and remember the EC) */
> cdev_init(>cdev, );
> @@ -203,7 +203,7 @@ static int ec_device_probe(struct platform_device *pdev)
> }
>
> ec->vdev = device_create(cros_class, NULL, devno, ec,
> -CROS_EC_DEV_NAME);
> +CROS_EC_DEV_NAME "%d", ec->id);
> if (IS_ERR(ec->vdev)) {
> retval = PTR_ERR(ec->vdev);
> dev_err(>dev, ": failed to create device\n");
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 7eee38abd02a..2bee6ac74ffb 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -72,6 +72,7 @@ struct cros_ec_command {
> *
> * @priv: Private data
> * @irq: Interrupt to use
> + * @id: Device id
> * @din: input buffer (for data from EC)
> * @dout: output buffer (for data to EC)
> * \note
> @@ -106,6 +107,7 @@ struct cros_ec_device {
> /* These are used to implement the platform-specific interface */
> void *priv;
> int irq;
> + int id;
> uint8_t *din;
> uint8_t *dout;
> int din_size;
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] checkpatch: suggest using eth_zero_addr() and eth_broadcast_addr()
On Thu, 2015-04-23 at 21:53 +0200, Mateusz Kulikowski wrote:
> On 22.04.2015 00:27, Joe Perches wrote:
> > On Tue, 2015-04-21 at 23:44 +0200, Mateusz Kulikowski wrote:
> >> On 21.04.2015 23:22, Joe Perches wrote:
> >>> On Tue, 2015-04-21 at 22:57 +0200, Mateusz Kulikowski wrote:
> >> (...)
> (...)
> >> True, True; If you prefer $line and ability to --fix - I'll use that in v3
> >
> > I suppose you could do both $line and $stat
> > and the fix would only work when it's on a
> > single line.
> >
> > Perhaps something like this would work:
> >
> > if ($line =~ /whatever/ ||
> > (defined($stat) && $stat =~ /whatever/)) {
> > if (WARN(...) &&
> > $fix) {
> > fixed[$fixlinenr] =~ s/whatever/appropriate/;
> > }
> > }
>
> Isn't it enough to just match $stat and do fix for line (that in
> some cases will just not match)?
Yeah, that'd work too.
> One more thing
> I noticed funny behavior about $stat matches -
> it reports the same error several times (including as "scope" whole file)
> Is it feature or "feature" or I missed something?
You have to make sure the first character of $stat is a +
if ($stat =~ /\+(?:.*)\bmem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fixed multiple spelling errors.
Fixed multiple spellig errors.
Signed-off-by: Carlos E. Garcia
---
drivers/staging/android/ion/ion_priv.h| 6 +-
drivers/staging/android/uapi/ion.h| 2 +-
drivers/staging/comedi/comedi_fops.c | 2 +-
drivers/staging/dgnc/TODO | 6 +-
drivers/staging/dgnc/dgnc_neo.c | 2 +-
drivers/staging/emxx_udc/emxx_udc.c | 2 +-
drivers/staging/fbtft/Kconfig | 2 +-
drivers/staging/fwserial/dma_fifo.c | 2 +-
drivers/staging/fwserial/fwserial.h | 2 +-
drivers/staging/iio/Documentation/device.txt | 2 +-
drivers/staging/iio/iio_simple_dummy.h| 2 +-
drivers/staging/lustre/TODO | 2 +-
drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +-
drivers/staging/octeon-usb/octeon-hcd.c | 4 +-
drivers/staging/octeon-usb/octeon-hcd.h | 2 +-
drivers/staging/rtl8188eu/include/rtl8188e_hal.h | 4 +-
drivers/staging/rtl8192u/r8192U_dm.c | 2 +-
drivers/staging/rtl8712/rtl8712_xmit.c| 2 +-
drivers/staging/rtl8712/rtl871x_mp_phy_regdef.h | 2 +-
drivers/staging/rtl8723au/hal/HalPwrSeqCmd.c | 2 +-
drivers/staging/rtl8723au/hal/odm.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_phycfg.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_rf6052.c | 4 +-
drivers/staging/rtl8723au/hal/rtl8723au_xmit.c| 2 +-
drivers/staging/rtl8723au/hal/usb_halinit.c | 2 +-
drivers/staging/rtl8723au/include/odm_debug.h | 2 +-
drivers/staging/rtl8723au/include/rtl8723a_hal.h | 2 +-
drivers/staging/rtl8723au/include/rtw_cmd.h | 2 +-
drivers/staging/rtl8723au/include/rtw_mlme.h | 10 +--
drivers/staging/rtl8723au/include/rtw_mlme_ext.h | 2 +-
drivers/staging/rtl8723au/include/sta_info.h | 2 +-
drivers/staging/sm750fb/ddk750_help.h | 2 +-
drivers/staging/sm750fb/ddk750_mode.c | 2 +-
drivers/staging/sm750fb/ddk750_reg.h | 4 +-
drivers/staging/sm750fb/ddk750_sii164.c | 4 +-
drivers/staging/sm750fb/readme| 8 +--
drivers/staging/sm750fb/sm750.c | 12 ++--
drivers/staging/sm750fb/sm750_accel.c | 4 +-
drivers/staging/sm750fb/sm750_hw.h| 2 +-
drivers/staging/unisys/include/guestlinuxdebug.h | 2 +-
drivers/staging/vt6655/rxtx.c | 2 +-
kernel/audit.c| 47 +++-
kernel/audit.h| 3 +
kernel/audit_tree.c | 88 +++
kernel/auditsc.c | 9 +--
46 files changed, 159 insertions(+), 118 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion_priv.h
index 18a5f93..52f1cd1 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -33,7 +33,7 @@ struct ion_buffer *ion_handle_buffer(struct ion_handle
*handle);
/**
* struct ion_buffer - metadata for a particular buffer
- * @ref: refernce count
+ * @ref: reference count
* @node: node in the ion_device buffers tree
* @dev: back pointer to the ion_device
* @heap: back pointer to the heap the buffer came from
@@ -46,7 +46,7 @@ struct ion_buffer *ion_handle_buffer(struct ion_handle
*handle);
* an ion_phys_addr_t (and someday a phys_addr_t)
* @lock: protects the buffers cnt fields
* @kmap_cnt: number of times the buffer is mapped to the kernel
- * @vaddr: the kenrel mapping if kmap_cnt is not zero
+ * @vaddr: the kernel mapping if kmap_cnt is not zero
* @dmap_cnt: number of times the buffer is mapped for dma
* @sg_table: the sg table for the buffer if dmap_cnt is not zero
* @pages: flat array of pages in the buffer -- used by fault
@@ -266,7 +266,7 @@ void ion_heap_freelist_add(struct ion_heap *heap, struct
ion_buffer *buffer);
/**
* ion_heap_freelist_drain - drain the deferred free list
* @heap: the heap
- * @size: ammount of memory to drain in bytes
+ * @size: amount of memory to drain in bytes
*
* Drains the indicated amount of memory from the deferred freelist
immediately.
* Returns the total amount freed. The total freed may be higher depending
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 6aa4956..68a14b4 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -179,7 +179,7 @@ struct ion_custom_data {
* DOC: ION_IOC_SYNC - syncs a shared file descriptors to memory
*
* Deprecated in favor of using the dma_buf api's correctly
[Update][PATCH] ACPI / scan: Add a scan handler for PRP0001
From: Rafael J. Wysocki
If the special PRP0001 device ID is present in the given device's list
of ACPI/PNP IDs and the device has a valid "compatible" property in
the _DSD, it should be enumerated using the default mechanism,
unless some scan handlers match the IDs preceding PRP0001 in the
device's list of ACPI/PNP IDs. In addition to that, no scan handlers
matching the IDs following PRP0001 in that list should be attached
to the device.
To make that happen, define a scan handler that will match PRP0001
and trigger the default enumeration for the matching devices if the
"compatible" property is present for them.
Since that requires the check for platform_id and device->handler
to be removed from acpi_default_enumeration(), move the fallback
invocation of acpi_default_enumeration() to acpi_bus_attach()
(after it's checked if there's a matching ACPI driver for the
device), which is a better place to call it, and do the platform_id
check in there too (device->handler is guaranteed to be unset at
the point where the function is looking for a matching ACPI driver).
Signed-off-by: Rafael J. Wysocki
Acked-by: Darren Hart
---
The change from the original patch is to change the scan handler
behavior to make it return 1 also if the "compatible" property is
not present, in which case the additional scan handlers should not
trigger too *and* the default enumeration should not trigger either
(as there's no ID to match to), which will allow things like
auxiliary nodes (think GPIO buttons/LEDs etc) to be easily represented.
Darren, I've tentatively added your Acked-by tag to this one, please
let me know if that's not appropriate.
Rafael
---
drivers/acpi/scan.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -2388,9 +2388,6 @@ static void acpi_default_enumeration(str
struct list_head resource_list;
bool is_spi_i2c_slave = false;
- if (!device->pnp.type.platform_id || device->handler)
- return;
-
/*
* Do not enemerate SPI/I2C slaves as they will be enuerated by their
* respective parents.
@@ -2403,6 +2400,29 @@ static void acpi_default_enumeration(str
acpi_create_platform_device(device);
}
+static const struct acpi_device_id generic_device_ids[] = {
+ {"PRP0001", },
+ {"", },
+};
+
+static int acpi_generic_device_attach(struct acpi_device *adev,
+ const struct acpi_device_id *not_used)
+{
+ /*
+* Since PRP0001 is the only ID handled here, the test below can be
+* unconditional.
+*/
+ if (adev->data.of_compatible)
+ acpi_default_enumeration(adev);
+
+ return 1;
+}
+
+static struct acpi_scan_handler generic_device_handler = {
+ .ids = generic_device_ids,
+ .attach = acpi_generic_device_attach,
+};
+
static int acpi_scan_attach_handler(struct acpi_device *device)
{
struct acpi_hardware_id *hwid;
@@ -2428,8 +2448,6 @@ static int acpi_scan_attach_handler(stru
break;
}
}
- if (!ret)
- acpi_default_enumeration(device);
return ret;
}
@@ -2471,6 +2489,9 @@ static void acpi_bus_attach(struct acpi_
ret = device_attach(>dev);
if (ret < 0)
return;
+
+ if (!ret && device->pnp.type.platform_id)
+ acpi_default_enumeration(device);
}
device->flags.visited = true;
@@ -2629,6 +2650,8 @@ int __init acpi_scan_init(void)
acpi_pnp_init();
acpi_int340x_thermal_init();
+ acpi_scan_add_handler(_device_handler);
+
mutex_lock(_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Interacting with coherent memory on external devices
On Thu, 2015-04-23 at 09:10 -0500, Christoph Lameter wrote: > On Thu, 23 Apr 2015, Benjamin Herrenschmidt wrote: > > > > Anyone > > > wanting performance (and that is the prime reason to use a GPU) would > > > switch this off because the latencies are otherwise not controllable and > > > those may impact performance severely. There are typically multiple > > > parallel strands of executing that must execute with similar performance > > > in order to allow a data exchange at defined intervals. That is no longer > > > possible if you add variances that come with the "transparency" here. > > > > Stop trying to apply your unique usage model to the entire world :-) > > Much of the HPC apps that the world is using is severely impacted by what > you are proposing. Its the industries usage model not mine. That is why I > was asking about the use case. Does not seem to fit the industry you are > targeting. This is also the basic design principle that got GPUs to work > as fast as they do today. Introducing random memory latencies there will > kill much of the benefit of GPUs there too. How would it be impacted ? You can still do dedicated allocations etc... if you want to do so. I think Jerome gave a pretty good explanation of the need for the usage model we are proposing, it's also coming from the industry ... Ben. > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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/
mmotm 2015-04-23-16-38 uploaded
The mm-of-the-moment snapshot 2015-04-23-16-38 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.0: (patches marked "*" will be included in linux-next) origin.patch arch-alpha-kernel-systblss-remove-debug-check.patch * revert-zram-move-compact_store-to-sysfs-functions-area.patch * zram-add-designated-reviewer-for-zram-in-maintainers.patch * lib-delete-lib-find_last_bitc.patch * mm-memory-failure-call-shake_page-when-error-hits-thp-tail-page.patch * compiler-gcch-neatening.patch * compiler-gcc-integrate-the-various-compiler-gcch-files.patch * kasan-show-gcc-version-requirements-in-kconfig-and-documentation.patch * documentation-bindings-add-abraconabx80x.patch * rtc-add-rtc-abx80x-a-driver-for-the-abracon-ab-x80x-i2c-rtc.patch * rtc-add-rtc-abx80x-a-driver-for-the-abracon-ab-x80x-i2c-rtc-v3.patch * mm-soft-offline-fix-num_poisoned_pages-counting-on-concurrent-events.patch * mm-hwpoison-inject-fix-refcounting-in-no-injection-case.patch * mm-hwpoison-inject-check-pagelru-of-hpage.patch * mm-x86-document-return-values-of-mapping-funcs.patch * mtrr-x86-fix-mtrr-lookup-to-handle-inclusive-entry.patch * mtrr-x86-remove-a-wrong-address-check-in-__mtrr_type_lookup.patch * mtrr-x86-fix-mtrr-state-checks-in-mtrr_type_lookup.patch * mtrr-x86-define-mtrr_type_invalid-for-mtrr_type_lookup.patch * mtrr-x86-clean-up-mtrr_type_lookup.patch * mtrr-mm-x86-enhance-mtrr-checks-for-kva-huge-page-mapping.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * jbd2-revert-must-not-fail-allocation-loops-back-to-gfp_nofail.patch * ocfs2-reduce-object-size-of-mlog-uses.patch * ocfs2-reduce-object-size-of-mlog-uses-fix.patch * ocfs2-remove-__mlog_cpu_guess.patch * ocfs2-remove-__mlog_cpu_guess-fix.patch * ocfs2-fix-a-tiny-race-when-truncate-dio-orohaned-entry.patch * ocfs2-set-filesytem-read-only-when-ocfs2_delete_entry-failed.patch * ocfs2-trusted-xattr-missing-cap_sys_admin-check.patch * ocfs2-flush-inode-data-to-disk-and-free-inode-when-i_count-becomes-zero.patch * add-errors=continue.patch * acknowledge-return-value-of-ocfs2_error.patch * clear-the-rest-of-the-buffers-on-error.patch * ocfs2-fix-a-tiny-case-that-inode-can-not-removed.patch * ocfs2-use-64bit-variables-to-track-heartbeat-time.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch * ocfs2-neaten-do_error-ocfs2_error-and-ocfs2_abort.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * posix_acl-make-posix_acl_create-safer-and-cleaner.patch * watchdog-fix-watchdog_nmi_enable_all.patch mm.patch *
Re: Re: [PATCH perf/core v2 3/8] perf probe: Accept multiple filter options
(2015/04/23 23:55), Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 23, 2015 at 10:46:17PM +0900, Masami Hiramatsu escreveu:
>> Accept multiple filter options. Each filters are combined
>> by logical-or. E.g. --filter abc* --filter *def is same
>> as --filter abc*|*def
>
> Please break this patch in two, one introducing the new strfilter
> functionality, the other making perf-probe use it.
>
> This way if later I had to revert the perf-probe part but keep the
> strfilter, if used by a later patch, that would be possible.
>
> I.e. in general please try to add new functionality for a library
> function in a patch and the actual use of it in another patch.
OK, I'll split strfilter features(__or, __string) out from
these patches.
> I applied the first two, and will continue after you reply to this,
> thanks!
thanks!
>
> - Arnaldo
>
>> Signed-off-by: Masami Hiramatsu
>> ---
>> tools/perf/builtin-probe.c | 14 +-
>> tools/perf/util/strfilter.c | 34 ++
>> tools/perf/util/strfilter.h | 13 +
>> 3 files changed, 56 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
>> index 92dcce0..be17075 100644
>> --- a/tools/perf/builtin-probe.c
>> +++ b/tools/perf/builtin-probe.c
>> @@ -262,21 +262,25 @@ static int opt_set_filter(const struct option *opt
>> __maybe_unused,
>>const char *str, int unset __maybe_unused)
>> {
>> const char *err;
>> +int ret = 0;
>>
>> if (str) {
>> pr_debug2("Set filter: %s\n", str);
>> -if (params.filter)
>> -strfilter__delete(params.filter);
>> -params.filter = strfilter__new(str, );
>> if (!params.filter) {
>> +params.filter = strfilter__new(str, );
>> +if (!params.filter)
>> +ret = err ? -EINVAL : -ENOMEM;
>> +} else
>> +ret = strfilter__or(params.filter, str, );
>> +
>> +if (ret == -EINVAL) {
>> pr_err("Filter parse error at %td.\n", err - str + 1);
>> pr_err("Source: \"%s\"\n", str);
>> pr_err(" %*c\n", (int)(err - str + 1), '^');
>> -return -EINVAL;
>> }
>> }
>>
>> -return 0;
>> +return ret;
>> }
>>
>> static int init_params(void)
>> diff --git a/tools/perf/util/strfilter.c b/tools/perf/util/strfilter.c
>> index 79a757a..cd659e6 100644
>> --- a/tools/perf/util/strfilter.c
>> +++ b/tools/perf/util/strfilter.c
>> @@ -170,6 +170,40 @@ struct strfilter *strfilter__new(const char *rules,
>> const char **err)
>> return filter;
>> }
>>
>> +static int strfilter__add(struct strfilter *filter, bool _or, const char
>> *rules,
>> + const char **err)
>> +{
>> +struct strfilter_node *right, *root;
>> +const char *ep = NULL;
>> +
>> +if (!filter || !rules)
>> +return -EINVAL;
>> +
>> +right = strfilter_node__new(rules, );
>> +if (!right || *ep != '\0') {
>> +if (err)
>> +*err = ep;
>> +goto error;
>> +}
>> +root = strfilter_node__alloc(_or ? OP_or : OP_and, filter->root, right);
>> +if (!root) {
>> +ep = NULL;
>> +goto error;
>> +}
>> +
>> +filter->root = root;
>> +return 0;
>> +
>> +error:
>> +strfilter_node__delete(right);
>> +return ep ? -EINVAL : -ENOMEM;
>> +}
>> +
>> +int strfilter__or(struct strfilter *filter, const char *rules, const char
>> **err)
>> +{
>> +return strfilter__add(filter, true, rules, err);
>> +}
>> +
>> static bool strfilter_node__compare(struct strfilter_node *node,
>> const char *str)
>> {
>> diff --git a/tools/perf/util/strfilter.h b/tools/perf/util/strfilter.h
>> index fe611f3..c81ff97 100644
>> --- a/tools/perf/util/strfilter.h
>> +++ b/tools/perf/util/strfilter.h
>> @@ -29,6 +29,19 @@ struct strfilter {
>> struct strfilter *strfilter__new(const char *rules, const char **err);
>>
>> /**
>> + * strfilter__or - Add an additional rule by logical-or
>> + * @filter: Original string filter
>> + * @rules: Filter rule to add at left of the root of @filter
>> + * by using logical-and.
>> + * @err: Pointer which points an error detected on @rules
>> + *
>> + * Parse @rules and join it to the @filter by using logical-or.
>> + * Return 0 if success, or return the error code.
>> + */
>> +int strfilter__or(struct strfilter *filter,
>> + const char *rules, const char **err);
>> +
>> +/**
>> * strfilter__compare - compare given string and a string filter
>> * @filter: String filter
>> * @str: target string
> --
> To unsubscribe 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: [PATCH next] ocfs2: Reduce object size of mlog uses
On Fri, Apr 24, 2015 at 1:19 AM, Andrew Morton wrote: > On Thu, 23 Apr 2015 16:04:18 -0700 Mark Fasheh wrote: > >> > This code needs some pretty serious rework and rethink, perhaps >> > involving a change to the emitted info. I was hoping one of the ocfs2 >> > developers would take the bait, but they're all in hiding. >> >> If it functions the same and doesn't have a major performance change, I'm >> pretty sure it'll be fine. We sometimes ask customers to enable some of the >> debugging if they are having an issue. I would ask that it be tested >> on a live system - a local fs, no cluster or cluster config required. > > Is there a simpleton's guide to testing ocfs2 on a local disk? One > which assumes a starting point of "knows how to type". See http://docs.oracle.com/cd/E37670_01/E41138/html/ol_crlcl_ocfs2.html -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v6] kvm/fpu: Enable fully eager restore kvm FPU
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
>Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
>not have performance regression, and it can simplify the code.
>
>When compiling kernel on westmere, the performance of eager FPU
>is about 0.4% faster than lazy FPU.
>
>Signed-off-by: Liang Li
>Signed-off-by: Xudong Hao
>---
> arch/x86/include/asm/kvm_host.h | 1 -
> arch/x86/kvm/svm.c | 22 ++--
> arch/x86/kvm/vmx.c | 74 +++--
> arch/x86/kvm/x86.c | 8 +
> include/linux/kvm_host.h| 2 --
> 5 files changed, 9 insertions(+), 98 deletions(-)
>
>diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>index dea2e7e..5d84cc9 100644
>--- a/arch/x86/include/asm/kvm_host.h
>+++ b/arch/x86/include/asm/kvm_host.h
>@@ -743,7 +743,6 @@ struct kvm_x86_ops {
> void (*cache_reg)(struct kvm_vcpu *vcpu, enum kvm_reg reg);
> unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
> void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
>- void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
>
> void (*tlb_flush)(struct kvm_vcpu *vcpu);
>
>diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>index ce741b8..1b3b29b 100644
>--- a/arch/x86/kvm/svm.c
>+++ b/arch/x86/kvm/svm.c
>@@ -1087,7 +1087,6 @@ static void init_vmcb(struct vcpu_svm *svm)
> struct vmcb_control_area *control = >vmcb->control;
> struct vmcb_save_area *save = >vmcb->save;
>
>- svm->vcpu.fpu_active = 1;
> svm->vcpu.arch.hflags = 0;
>
> set_cr_intercept(svm, INTERCEPT_CR0_READ);
>@@ -1529,15 +1528,12 @@ static void update_cr0_intercept(struct vcpu_svm *svm)
> ulong gcr0 = svm->vcpu.arch.cr0;
> u64 *hcr0 = >vmcb->save.cr0;
>
>- if (!svm->vcpu.fpu_active)
>- *hcr0 |= SVM_CR0_SELECTIVE_MASK;
>- else
>- *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>- | (gcr0 & SVM_CR0_SELECTIVE_MASK);
>+ *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>+ | (gcr0 & SVM_CR0_SELECTIVE_MASK);
>
> mark_dirty(svm->vmcb, VMCB_CR);
>
>- if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
>+ if (gcr0 == *hcr0) {
> clr_cr_intercept(svm, INTERCEPT_CR0_READ);
> clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
> } else {
>@@ -1568,8 +1564,6 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
>long cr0)
> if (!npt_enabled)
> cr0 |= X86_CR0_PG | X86_CR0_WP;
>
>- if (!vcpu->fpu_active)
>- cr0 |= X86_CR0_TS;
> /*
>* re-enable caching here because the QEMU bios
>* does not do it - this results in some delay at
>@@ -1795,7 +1789,6 @@ static void svm_fpu_activate(struct kvm_vcpu *vcpu)
>
> clr_exception_intercept(svm, NM_VECTOR);
>
>- svm->vcpu.fpu_active = 1;
> update_cr0_intercept(svm);
> }
>
>@@ -4139,14 +4132,6 @@ static bool svm_has_wbinvd_exit(void)
> return true;
> }
>
>-static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
>-{
>- struct vcpu_svm *svm = to_svm(vcpu);
>-
>- set_exception_intercept(svm, NM_VECTOR);
>- update_cr0_intercept(svm);
>-}
Do you test it on AMD cpu? What's the performance you get?
Regards,
Wanpeng Li
>-
> #define PRE_EX(exit) { .exit_code = (exit), \
> .stage = X86_ICPT_PRE_EXCEPT, }
> #define POST_EX(exit) { .exit_code = (exit), \
>@@ -4381,7 +4366,6 @@ static struct kvm_x86_ops svm_x86_ops = {
> .cache_reg = svm_cache_reg,
> .get_rflags = svm_get_rflags,
> .set_rflags = svm_set_rflags,
>- .fpu_deactivate = svm_fpu_deactivate,
>
> .tlb_flush = svm_flush_tlb,
>
>diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>index f5e8dce..811a666 100644
>--- a/arch/x86/kvm/vmx.c
>+++ b/arch/x86/kvm/vmx.c
>@@ -1567,7 +1567,7 @@ static void update_exception_bitmap(struct kvm_vcpu
>*vcpu)
> u32 eb;
>
> eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
>- (1u << NM_VECTOR) | (1u << DB_VECTOR);
>+ (1u << DB_VECTOR);
> if ((vcpu->guest_debug &
>(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
> (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
>@@ -1576,8 +1576,6 @@ static void update_exception_bitmap(struct kvm_vcpu
>*vcpu)
> eb = ~0;
> if (enable_ept)
> eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
>- if (vcpu->fpu_active)
>- eb &= ~(1u << NM_VECTOR);
>
> /* When we are running a nested L2 guest and L1 specified for it a
>* certain exception bitmap, we must trap the same exceptions and pass
>@@ -1961,9 +1959,6 @@ static void vmx_fpu_activate(struct kvm_vcpu *vcpu)
> {
> ulong cr0;
>
>- if (vcpu->fpu_active)
>- return;
>- vcpu->fpu_active = 1;
> cr0 = vmcs_readl(GUEST_CR0);
> cr0 &= ~(X86_CR0_TS | X86_CR0_MP);
>
Re: [PATCH next] ocfs2: Reduce object size of mlog uses
On Thu, 2015-04-23 at 16:04 -0700, Mark Fasheh wrote:
> On Wed, Apr 22, 2015 at 03:46:04PM -0700, Andrew Morton wrote:
> > If you feel like undertaking such a rotorooting then go wild - that should
> > wake 'em up ;)
>
> Ok, I've taken the bait :)
"Here fishy, fishy...", erm, "Here Fasheh, Fasheh..."
With that out of the way:
A couple of possibilities:
o I wonder whether or not file/func/line matter at all.
I think they don't.
Removing them would reduce code size ~90K
o There's a small logging improvement possible in tcp.c.
Both below:
--
fs/ocfs2/cluster/masklog.c | 7 +++
fs/ocfs2/cluster/masklog.h | 8 +++-
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
index fc5e522..8b9816f 100644
--- a/fs/ocfs2/cluster/masklog.c
+++ b/fs/ocfs2/cluster/masklog.c
@@ -77,8 +77,7 @@ static ssize_t mlog_mask_store(u64 mask, const char *buf,
size_t count)
_cpu; \
})
-void __mlog_printk(const u64 *mask, const char *func, int line,
- const char *fmt, ...)
+void __mlog_printk(const u64 *mask, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
@@ -103,9 +102,9 @@ void __mlog_printk(const u64 *mask, const char *func, int
line,
vaf.fmt = fmt;
vaf.va =
- printk("%s(%s,%u,%lu):%s:%d %s%pV",
+ printk("%s(%s,%u,%lu) %s%pV",
level, current->comm, task_pid_nr(current), __mlog_cpu_guess,
- func, line, prefix, );
+ prefix, );
va_end(args);
}
diff --git a/fs/ocfs2/cluster/masklog.h b/fs/ocfs2/cluster/masklog.h
index 308ea0e..9e93f19 100644
--- a/fs/ocfs2/cluster/masklog.h
+++ b/fs/ocfs2/cluster/masklog.h
@@ -162,9 +162,8 @@ extern struct mlog_bits mlog_and_bits, mlog_not_bits;
#endif
-__printf(4, 5)
-void __mlog_printk(const u64 *m, const char *func, int line,
- const char *fmt, ...);
+__printf(2, 3)
+void __mlog_printk(const u64 *m, const char *fmt, ...);
/*
* Testing before the __mlog_printk call lets the compiler eliminate the
@@ -174,8 +173,7 @@ void __mlog_printk(const u64 *m, const char *func, int line,
do { \
u64 _m = MLOG_MASK_PREFIX | (mask); \
if (_m & ML_ALLOWED_BITS) \
- __mlog_printk(&_m, __func__, __LINE__, fmt, \
- ##__VA_ARGS__); \
+ __mlog_printk(&_m, fmt, ##__VA_ARGS__); \
} while (0)
#define mlog_errno(st) ({ \
--
fs/ocfs2/cluster/tcp.c | 60 +++---
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 56c403a..2c74973 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -78,29 +78,43 @@
>sc_node->nd_ipv4_address,\
ntohs(sc->sc_node->nd_ipv4_port)
-/*
- * In the following two log macros, the whitespace after the ',' just
- * before ##args is intentional. Otherwise, gcc 2.95 will eat the
- * previous token if args expands to nothing.
- */
-#define msglog(hdr, fmt, args...) do { \
- typeof(hdr) __hdr = (hdr); \
- mlog(ML_MSG, "[mag %u len %u typ %u stat %d sys_stat %d " \
-"key %08x num %u] " fmt, \
-be16_to_cpu(__hdr->magic), be16_to_cpu(__hdr->data_len), \
-be16_to_cpu(__hdr->msg_type), be32_to_cpu(__hdr->status), \
-be32_to_cpu(__hdr->sys_status), be32_to_cpu(__hdr->key), \
-be32_to_cpu(__hdr->msg_num) , ##args);\
-} while (0)
-
-#define sclog(sc, fmt, args...) do { \
- typeof(sc) __sc = (sc); \
- mlog(ML_SOCKET, "[sc %p refs %d sock %p node %u page %p " \
-"pg_off %zu] " fmt, __sc, \
-atomic_read(&__sc->sc_kref.refcount), __sc->sc_sock, \
- __sc->sc_node->nd_num, __sc->sc_page, __sc->sc_page_off , \
- ##args);\
-} while (0)
+__printf(2, 3)
+void msglog(struct o2net_msg *hdr, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va =
+
+ mlog(ML_MSG, "[mag %u len %u typ %u stat %d sys_stat %d key %08x num
%u] %pV",
+be16_to_cpu(hdr->magic),
Re: Adding subpage support to NAND driver -- backwards compatibility concerns
Am 24.04.2015 um 01:13 schrieb Iwo Mergler: > On Fri, 24 Apr 2015 05:30:55 +1000 > Richard Weinberger wrote: > >> Am 23.04.2015 um 20:39 schrieb Josh Cartwright: > >>> Is there no metadata in the UBI data structures in flash that >>> indicate the min IO boundary? Assuming no, is another option to, >>> at the time of attach, try both the min IO access size, and, if >>> that doesn't work, try the page size? >> >> Correct. UBI has no information about that. >> If you add subpage support to the driver I'd make it opt-in such that >> existing setups won't break. > > I'm wondering, given that EC headers contain vid header offset > and data offset fields, shouldn't UBI be able to deduce at attach > time what the relevant parameters are on a partition? UBI double checks that offset. If the vid header offset does not match the run-time computed offset UBI will detect that in validate_ec_hdr(). So, yes it could automatically deduce it at attach time but it does not for safety reasons. UBI computes the values from the data provided by the MTD, if the image does not match it stops. If it would blindly trust the image it could happen that you operate on your MTD with a wrong page size. > Something along the lines of using the parameters of the first > PEB with valid EC header, then balking if another EC header is > encountered with different info. As long as MTD allows the > so deduced minimum access size, it seems safe. > > This could help enormously in situations like this, where > MTD drivers experience sudden bursts of improvement. Agreed. UBI could be more intelligent. If UBI can be sure that the parameters deduced from the on-flash image are safe with respect to the parameters provided by MTD it could continue. Maybe Artem can give us more details on that as he designed it. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/4] tracing: Add new hwlat_detector tracer
On Thu, 23 Apr 2015 15:50:29 -0700 Linus Torvalds wrote: > On Thu, Apr 23, 2015 at 1:21 PM, Thomas Gleixner wrote: > > > > But at least on the machines which have the event counter it would be > > usefull to include that information as well. > > In fact, I'd argue that we should *not* do this odd magic latency > measurement thing at all, exactly because Intel gave is the SMI > counter, and it's much more likely to be useful in real life. The odd > "stop machine and busy loop adn do magic" thing is a incredibly > invasive hack that sane people will never enable at all, while the No sane person should enable this on any production machine, and nor should they use the other latency tracer (irqsoff and friends). But we have used this odd magic latency measurement in dealings with vendors and such in certifying their machines. Thus, this has not been something that we just wanted to throw into the kernel for fun. This tool has actually been very helpful to us. > "add support for the hadrware we asked for and got" is a small thing > that we can do on all modern Intel chips, and can be enabled by > default because there is no downside. > What about a mix and match tracer? If the hardware supports SMI counters (and more importantly, SMI cycle counters), it will just use that, otherwise if the hardware does not support the SMI counting, it falls back to the odd magic latency measurement thing. I could even make the odd magic latency measurement thing only be enabled via a tracer flag, such that it would be safe to use the SMI counter if supported, but if it isn't supported, a tracing message will display info about the more invasive (not to be used in production environment) measurement. But the more invasive version will only be activated if the user explicitly set it (even if SMI counters were not available). And when this was first proposed, it was called smi_detector, and I believe it was Andrew that suggested to rename it to hwlat_detector, because it could theoretically, detect other types of hardware issues that could stop the CPU, in case something like that ever arise. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary
On Fri, Apr 24, 2015 at 1:04 AM, Linus Torvalds wrote: > And at that point,> the only cost is a a single no-op on most CPU's (we still > don't know > _which_ AMD CPU's are affected, but I guess we could start off with > all of them and see if we can get an exhaustive list some way). This seems to be "architectural" for AMD CPU's, similar to Intel's SYSRET bug with non-canonical return address. Meaning, both bugs, are documented by respective companies. Both are officially "not a bug, but a feature". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Adding subpage support to NAND driver -- backwards compatibility concerns
On Fri, 24 Apr 2015 05:30:55 +1000 Richard Weinberger wrote: > Am 23.04.2015 um 20:39 schrieb Josh Cartwright: > > Is there no metadata in the UBI data structures in flash that > > indicate the min IO boundary? Assuming no, is another option to, > > at the time of attach, try both the min IO access size, and, if > > that doesn't work, try the page size? > > Correct. UBI has no information about that. > If you add subpage support to the driver I'd make it opt-in such that > existing setups won't break. I'm wondering, given that EC headers contain vid header offset and data offset fields, shouldn't UBI be able to deduce at attach time what the relevant parameters are on a partition? Something along the lines of using the parameters of the first PEB with valid EC header, then balking if another EC header is encountered with different info. As long as MTD allows the so deduced minimum access size, it seems safe. This could help enormously in situations like this, where MTD drivers experience sudden bursts of improvement. Best regards, Iwo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH next] ocfs2: Reduce object size of mlog uses
On Thu, 23 Apr 2015 16:04:18 -0700 Mark Fasheh wrote: > > This code needs some pretty serious rework and rethink, perhaps > > involving a change to the emitted info. I was hoping one of the ocfs2 > > developers would take the bait, but they're all in hiding. > > If it functions the same and doesn't have a major performance change, I'm > pretty sure it'll be fine. We sometimes ask customers to enable some of the > debugging if they are having an issue. I would ask that it be tested > on a live system - a local fs, no cluster or cluster config required. Is there a simpleton's guide to testing ocfs2 on a local disk? One which assumes a starting point of "knows how to type". A few paragraphs in Documentation/filesystems/ocfs2.txt would be great - then we can point non-ocfs2 people at it when they muck with stuff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8] psmouse - focaltech pass finger width to userspace
Focaltech touchpads report finger width in packet[5] of absolute packet.
Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
0xff is reported, when a large contact area is detected.
This can be handled in userspace.
Signed-off-by: Dmitry Tunin
---
drivers/input/mouse/focaltech.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
index 23d2594..ea53f8b 100644
--- a/drivers/input/mouse/focaltech.c
+++ b/drivers/input/mouse/focaltech.c
@@ -90,6 +90,13 @@ struct focaltech_finger_state {
*/
unsigned int x;
unsigned int y;
+
+ /*
+ * Finger width 0-7 and 15 for 'latching'
+ * 15 value stays until the finger is released
+ * Width is reported only in absolute packets
+ */
+ unsigned int width;
};
/*
@@ -112,7 +119,7 @@ struct focaltech_data {
struct focaltech_hw_state state;
};
-static void focaltech_report_state(struct psmouse *psmouse)
+static void focaltech_report_state(struct psmouse *psmouse, bool abs)
{
struct focaltech_data *priv = psmouse->private;
struct focaltech_hw_state *state = >state;
@@ -137,6 +144,7 @@ static void focaltech_report_state(struct psmouse *psmouse)
input_report_abs(dev, ABS_MT_POSITION_X, clamped_x);
input_report_abs(dev, ABS_MT_POSITION_Y,
priv->y_max - clamped_y);
+ if (abs) input_report_abs(dev, ABS_TOOL_WIDTH,
state->width);
}
}
input_mt_report_pointer_emulation(dev, true);
@@ -187,6 +195,7 @@ static void focaltech_process_abs_packet(struct psmouse
*psmouse,
state->fingers[finger].x = ((packet[1] & 0xf) << 8) | packet[2];
state->fingers[finger].y = (packet[3] << 8) | packet[4];
+ state->fingers[finger].width = packet[5] >> 4;
state->fingers[finger].valid = true;
}
@@ -228,14 +237,17 @@ static void focaltech_process_packet(struct psmouse
*psmouse)
switch (packet[0] & 0xf) {
case FOC_TOUCH:
focaltech_process_touch_packet(psmouse, packet);
+ focaltech_report_state(psmouse, false);
break;
case FOC_ABS:
focaltech_process_abs_packet(psmouse, packet);
+ focaltech_report_state(psmouse, true);
break;
case FOC_REL:
focaltech_process_rel_packet(psmouse, packet);
+ focaltech_report_state(psmouse, false);
break;
default:
@@ -243,7 +255,6 @@ static void focaltech_process_packet(struct psmouse
*psmouse)
break;
}
- focaltech_report_state(psmouse);
}
static psmouse_ret_t focaltech_process_byte(struct psmouse *psmouse)
@@ -331,6 +342,7 @@ static void focaltech_set_input_params(struct psmouse
*psmouse)
__set_bit(EV_ABS, dev->evbit);
input_set_abs_params(dev, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
+ input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
input_mt_init_slots(dev, 5, INPUT_MT_POINTER);
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v6] kvm/fpu: Enable fully eager restore kvm FPU
Cc Rik, who is doing the similar work. :)
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
>Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
>not have performance regression, and it can simplify the code.
>
>When compiling kernel on westmere, the performance of eager FPU
>is about 0.4% faster than lazy FPU.
>
>Signed-off-by: Liang Li
>Signed-off-by: Xudong Hao
>---
> arch/x86/include/asm/kvm_host.h | 1 -
> arch/x86/kvm/svm.c | 22 ++--
> arch/x86/kvm/vmx.c | 74 +++--
> arch/x86/kvm/x86.c | 8 +
> include/linux/kvm_host.h| 2 --
> 5 files changed, 9 insertions(+), 98 deletions(-)
>
>diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>index dea2e7e..5d84cc9 100644
>--- a/arch/x86/include/asm/kvm_host.h
>+++ b/arch/x86/include/asm/kvm_host.h
>@@ -743,7 +743,6 @@ struct kvm_x86_ops {
> void (*cache_reg)(struct kvm_vcpu *vcpu, enum kvm_reg reg);
> unsigned long (*get_rflags)(struct kvm_vcpu *vcpu);
> void (*set_rflags)(struct kvm_vcpu *vcpu, unsigned long rflags);
>- void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
>
> void (*tlb_flush)(struct kvm_vcpu *vcpu);
>
>diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>index ce741b8..1b3b29b 100644
>--- a/arch/x86/kvm/svm.c
>+++ b/arch/x86/kvm/svm.c
>@@ -1087,7 +1087,6 @@ static void init_vmcb(struct vcpu_svm *svm)
> struct vmcb_control_area *control = >vmcb->control;
> struct vmcb_save_area *save = >vmcb->save;
>
>- svm->vcpu.fpu_active = 1;
> svm->vcpu.arch.hflags = 0;
>
> set_cr_intercept(svm, INTERCEPT_CR0_READ);
>@@ -1529,15 +1528,12 @@ static void update_cr0_intercept(struct vcpu_svm *svm)
> ulong gcr0 = svm->vcpu.arch.cr0;
> u64 *hcr0 = >vmcb->save.cr0;
>
>- if (!svm->vcpu.fpu_active)
>- *hcr0 |= SVM_CR0_SELECTIVE_MASK;
>- else
>- *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>- | (gcr0 & SVM_CR0_SELECTIVE_MASK);
>+ *hcr0 = (*hcr0 & ~SVM_CR0_SELECTIVE_MASK)
>+ | (gcr0 & SVM_CR0_SELECTIVE_MASK);
>
> mark_dirty(svm->vmcb, VMCB_CR);
>
>- if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
>+ if (gcr0 == *hcr0) {
> clr_cr_intercept(svm, INTERCEPT_CR0_READ);
> clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
> } else {
>@@ -1568,8 +1564,6 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
>long cr0)
> if (!npt_enabled)
> cr0 |= X86_CR0_PG | X86_CR0_WP;
>
>- if (!vcpu->fpu_active)
>- cr0 |= X86_CR0_TS;
> /*
>* re-enable caching here because the QEMU bios
>* does not do it - this results in some delay at
>@@ -1795,7 +1789,6 @@ static void svm_fpu_activate(struct kvm_vcpu *vcpu)
>
> clr_exception_intercept(svm, NM_VECTOR);
>
>- svm->vcpu.fpu_active = 1;
> update_cr0_intercept(svm);
> }
>
>@@ -4139,14 +4132,6 @@ static bool svm_has_wbinvd_exit(void)
> return true;
> }
>
>-static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
>-{
>- struct vcpu_svm *svm = to_svm(vcpu);
>-
>- set_exception_intercept(svm, NM_VECTOR);
>- update_cr0_intercept(svm);
>-}
>-
> #define PRE_EX(exit) { .exit_code = (exit), \
> .stage = X86_ICPT_PRE_EXCEPT, }
> #define POST_EX(exit) { .exit_code = (exit), \
>@@ -4381,7 +4366,6 @@ static struct kvm_x86_ops svm_x86_ops = {
> .cache_reg = svm_cache_reg,
> .get_rflags = svm_get_rflags,
> .set_rflags = svm_set_rflags,
>- .fpu_deactivate = svm_fpu_deactivate,
>
> .tlb_flush = svm_flush_tlb,
>
>diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>index f5e8dce..811a666 100644
>--- a/arch/x86/kvm/vmx.c
>+++ b/arch/x86/kvm/vmx.c
>@@ -1567,7 +1567,7 @@ static void update_exception_bitmap(struct kvm_vcpu
>*vcpu)
> u32 eb;
>
> eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
>- (1u << NM_VECTOR) | (1u << DB_VECTOR);
>+ (1u << DB_VECTOR);
> if ((vcpu->guest_debug &
>(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
> (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
>@@ -1576,8 +1576,6 @@ static void update_exception_bitmap(struct kvm_vcpu
>*vcpu)
> eb = ~0;
> if (enable_ept)
> eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
>- if (vcpu->fpu_active)
>- eb &= ~(1u << NM_VECTOR);
>
> /* When we are running a nested L2 guest and L1 specified for it a
>* certain exception bitmap, we must trap the same exceptions and pass
>@@ -1961,9 +1959,6 @@ static void vmx_fpu_activate(struct kvm_vcpu *vcpu)
> {
> ulong cr0;
>
>- if (vcpu->fpu_active)
>- return;
>- vcpu->fpu_active = 1;
> cr0 = vmcs_readl(GUEST_CR0);
> cr0 &= ~(X86_CR0_TS | X86_CR0_MP);
> cr0 |= kvm_read_cr0_bits(vcpu,
[PATCH] psmouse - focaltech pass finger width to userspace
Focaltech touchpads report finger width in packet[5] of absolute packet.
Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
0xff is reported, when a large contact area is detected.
This can be handled in userspace.
---
drivers/input/mouse/focaltech.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
index 23d2594..ea53f8b 100644
--- a/drivers/input/mouse/focaltech.c
+++ b/drivers/input/mouse/focaltech.c
@@ -90,6 +90,13 @@ struct focaltech_finger_state {
*/
unsigned int x;
unsigned int y;
+
+ /*
+ * Finger width 0-7 and 15 for 'latching'
+ * 15 value stays until the finger is released
+ * Width is reported only in absolute packets
+ */
+ unsigned int width;
};
/*
@@ -112,7 +119,7 @@ struct focaltech_data {
struct focaltech_hw_state state;
};
-static void focaltech_report_state(struct psmouse *psmouse)
+static void focaltech_report_state(struct psmouse *psmouse, bool abs)
{
struct focaltech_data *priv = psmouse->private;
struct focaltech_hw_state *state = >state;
@@ -137,6 +144,7 @@ static void focaltech_report_state(struct psmouse *psmouse)
input_report_abs(dev, ABS_MT_POSITION_X, clamped_x);
input_report_abs(dev, ABS_MT_POSITION_Y,
priv->y_max - clamped_y);
+ if (abs) input_report_abs(dev, ABS_TOOL_WIDTH,
state->width);
}
}
input_mt_report_pointer_emulation(dev, true);
@@ -187,6 +195,7 @@ static void focaltech_process_abs_packet(struct psmouse
*psmouse,
state->fingers[finger].x = ((packet[1] & 0xf) << 8) | packet[2];
state->fingers[finger].y = (packet[3] << 8) | packet[4];
+ state->fingers[finger].width = packet[5] >> 4;
state->fingers[finger].valid = true;
}
@@ -228,14 +237,17 @@ static void focaltech_process_packet(struct psmouse
*psmouse)
switch (packet[0] & 0xf) {
case FOC_TOUCH:
focaltech_process_touch_packet(psmouse, packet);
+ focaltech_report_state(psmouse, false);
break;
case FOC_ABS:
focaltech_process_abs_packet(psmouse, packet);
+ focaltech_report_state(psmouse, true);
break;
case FOC_REL:
focaltech_process_rel_packet(psmouse, packet);
+ focaltech_report_state(psmouse, false);
break;
default:
@@ -243,7 +255,6 @@ static void focaltech_process_packet(struct psmouse
*psmouse)
break;
}
- focaltech_report_state(psmouse);
}
static psmouse_ret_t focaltech_process_byte(struct psmouse *psmouse)
@@ -331,6 +342,7 @@ static void focaltech_set_input_params(struct psmouse
*psmouse)
__set_bit(EV_ABS, dev->evbit);
input_set_abs_params(dev, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
+ input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
input_mt_init_slots(dev, 5, INPUT_MT_POINTER);
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ibmveth: Fix off-by-one error in ibmveth_change_mtu()
On 04/22/2015 02:42 PM, Thomas Falcon wrote:
> On 04/20/2015 08:07 PM, David Gibson wrote:
>> AFAIK the PAPR document which defines the virtual device interface used by
>> the ibmveth driver doesn't specify a specific maximum MTU. So, in the
PAPR itself doesn't, but the max-frame-size property, which I understand
to be synonymous with max MTU, is required by PAPR to be present in the
Logical LAN OF node corresponding to the ibmveth device.
-Tyrel
>> ibmveth driver, the maximum allowed MTU is determined by the maximum
>> allocated buffer size of 64k (corresponding to one page in the common case)
>> minus the per-buffer overhead IBMVETH_BUFF_OH (which has value 22 for 14
>> bytes of ethernet header, plus 8 bytes for an opaque handle).
>>
>> This suggests a maximum allowable MTU of 65514 bytes, but in fact the
>> driver only permits a maximum MTU of 65513. This is because there is a <
>> instead of an <= in ibmveth_change_mtu(), which only permits an MTU which
>> is strictly smaller than the buffer size, rather than allowing the buffer
>> to be completely filled.
>>
>> This patch fixes the buglet.
>
> Thanks!
>
> Acked-by: Thomas Falcon
>
>>
>> Signed-off-by: David Gibson 1
>> ---
>> drivers/net/ethernet/ibm/ibmveth.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Changes since v1:
>> * Fixed a second instance of the same off-by-one error. Thanks to
>>Thomas Falcon for spotting this.
>>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c
>> b/drivers/net/ethernet/ibm/ibmveth.c
>> index cd7675a..1813476 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
>> @@ -1238,7 +1238,7 @@ static int ibmveth_change_mtu(struct net_device *dev,
>> int new_mtu)
>> return -EINVAL;
>>
>> for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++)
>> -if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size)
>> +if (new_mtu_oh <= adapter->rx_buff_pool[i].buff_size)
>> break;
>>
>> if (i == IBMVETH_NUM_BUFF_POOLS)
>> @@ -1257,7 +1257,7 @@ static int ibmveth_change_mtu(struct net_device *dev,
>> int new_mtu)
>> for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++) {
>> adapter->rx_buff_pool[i].active = 1;
>>
>> -if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size) {
>> +if (new_mtu_oh <= adapter->rx_buff_pool[i].buff_size) {
>> dev->mtu = new_mtu;
>> vio_cmo_set_dev_desired(viodev,
>> ibmveth_get_desired_dma
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] md/raid10: make sync_request_write() call bio_copy_data()
From: Kent Overstreet
Refactor sync_request_write() of md/raid10 to use bio_copy_data()
instead of open coding bio_vec iterations.
Cc: Christoph Hellwig
Cc: Neil Brown
Cc: linux-r...@vger.kernel.org
Signed-off-by: Kent Overstreet
[dpark: add more description in commit message]
Signed-off-by: Dongsu Park
Signed-off-by: Ming Lin
---
drivers/md/raid10.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index a7196c4..02e33f1 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2097,18 +2097,11 @@ static void sync_request_write(struct mddev *mddev,
struct r10bio *r10_bio)
tbio->bi_vcnt = vcnt;
tbio->bi_iter.bi_size = r10_bio->sectors << 9;
tbio->bi_rw = WRITE;
- tbio->bi_private = r10_bio;
tbio->bi_iter.bi_sector = r10_bio->devs[i].addr;
-
- for (j=0; j < vcnt ; j++) {
- tbio->bi_io_vec[j].bv_offset = 0;
- tbio->bi_io_vec[j].bv_len = PAGE_SIZE;
-
- memcpy(page_address(tbio->bi_io_vec[j].bv_page),
- page_address(fbio->bi_io_vec[j].bv_page),
- PAGE_SIZE);
- }
tbio->bi_end_io = end_sync_write;
+ tbio->bi_private = r10_bio;
+
+ bio_copy_data(tbio, fbio);
d = r10_bio->devs[i].devnum;
atomic_inc(>mirrors[d].rdev->nr_pending);
@@ -2124,17 +2117,14 @@ static void sync_request_write(struct mddev *mddev,
struct r10bio *r10_bio)
* that are active
*/
for (i = 0; i < conf->copies; i++) {
- int j, d;
+ int d;
tbio = r10_bio->devs[i].repl_bio;
if (!tbio || !tbio->bi_end_io)
continue;
if (r10_bio->devs[i].bio->bi_end_io != end_sync_write
&& r10_bio->devs[i].bio != fbio)
- for (j = 0; j < vcnt; j++)
- memcpy(page_address(tbio->bi_io_vec[j].bv_page),
- page_address(fbio->bi_io_vec[j].bv_page),
- PAGE_SIZE);
+ bio_copy_data(tbio, fbio);
d = r10_bio->devs[i].devnum;
atomic_inc(_bio->remaining);
md_sync_acct(conf->mirrors[d].replacement->bdev,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] fs: make _submit_bh consistent with generic bio chaining
From: Kent Overstreet
Make _submit_bh() handle refcounting by increasing bio->bi_remaining,
followed by bio_endio(). Since bio chaining was introduced with
196d38bccfcf ("block: Generic bio chaining"), refcounting should be
done on bi_remaining instead of ancient bio_cnt. Doing that, calling
convention can be consistent with the immutable biovecs API.
Cc: Christoph Hellwig
Cc: Al Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Kent Overstreet
[dpark: add more description in commit message]
[mlin: rebase as Jens is changing the bi_remaining rules]
Signed-off-by: Dongsu Park
Signed-off-by: Ming Lin
---
fs/buffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index c7a5602..c1c0e0d 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3041,13 +3041,13 @@ int _submit_bh(int rw, struct buffer_head *bh, unsigned
long bio_flags)
if (buffer_prio(bh))
rw |= REQ_PRIO;
- bio_get(bio);
+ bio_inc_remaining(bio);
submit_bio(rw, bio);
if (bio_flagged(bio, BIO_EOPNOTSUPP))
ret = -EOPNOTSUPP;
- bio_put(bio);
+ bio_endio(bio, 0);
return ret;
}
EXPORT_SYMBOL_GPL(_submit_bh);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] PM: submit bio in a sane way in cases without bio_chain
From: Kent Overstreet
Make bio submission in kernel/power/block_io.c to properly submit
bios also when bio_chain is not available. In that case, it's not
necessary to handle refcount with bio_get(), but it's saner to simply
call a predefined helper submit_bio_wait(). So call bio_get() only
when bio_chain is given.
Cc: Christoph Hellwig
Cc: linux...@vger.kernel.org
Acked-by: Rafael J. Wysocki
Signed-off-by: Kent Overstreet
[dpark: add more description in commit message]
Signed-off-by: Dongsu Park
Signed-off-by: Ming Lin
---
kernel/power/block_io.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/kernel/power/block_io.c b/kernel/power/block_io.c
index 9a58bc2..7206408 100644
--- a/kernel/power/block_io.c
+++ b/kernel/power/block_io.c
@@ -34,7 +34,6 @@ static int submit(int rw, struct block_device *bdev, sector_t
sector,
bio = bio_alloc(__GFP_WAIT | __GFP_HIGH, 1);
bio->bi_iter.bi_sector = sector;
bio->bi_bdev = bdev;
- bio->bi_end_io = end_swap_bio_read;
if (bio_add_page(bio, page, PAGE_SIZE, 0) < PAGE_SIZE) {
printk(KERN_ERR "PM: Adding page to bio failed at %llu\n",
@@ -44,15 +43,29 @@ static int submit(int rw, struct block_device *bdev,
sector_t sector,
}
lock_page(page);
- bio_get(bio);
if (bio_chain == NULL) {
- submit_bio(bio_rw, bio);
- wait_on_page_locked(page);
+ int err = submit_bio_wait(bio_rw, bio);
+
+ if (err) {
+ SetPageError(page);
+ ClearPageUptodate(page);
+ pr_alert("Read-error on swap-device (%u:%u:%llu)\n",
+imajor(bio->bi_bdev->bd_inode),
+iminor(bio->bi_bdev->bd_inode),
+(unsigned long long)bio->bi_iter.bi_sector);
+ } else {
+ SetPageUptodate(page);
+ }
+
if (rw == READ)
- bio_set_pages_dirty(bio);
+ set_page_dirty_lock(page);
+ unlock_page(page);
bio_put(bio);
} else {
+ bio->bi_end_io = end_swap_bio_read;
+ bio_get(bio);
+
if (rw == READ)
get_page(page); /* These pages are freed later */
bio->bi_private = *bio_chain;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] block: refactor iov_count_pages() from bio_{copy,map}_user_iov()
From: Kent Overstreet
Refactor the common part in bio_copy_user_iov() and
__bio_map_user_iov() to separate out iov_count_pages() into the general
iov_iter API, instead of open coding iov iterations as done previously.
This commit should contain only literal replacements, without
functional changes.
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: "Hans J. Koch"
Cc: Greg Kroah-Hartman
Cc: Al Viro
Signed-off-by: Kent Overstreet
[dpark: add more description in commit message]
[mlin: move iov_count_pages to block/bio.c]
Signed-off-by: Dongsu Park
Signed-off-by: Ming Lin
---
block/bio.c | 70 +
1 file changed, 33 insertions(+), 37 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 05c2864..eb4471a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1139,6 +1139,33 @@ int bio_uncopy_user(struct bio *bio)
}
EXPORT_SYMBOL(bio_uncopy_user);
+static int iov_count_pages(const struct iov_iter *iter, unsigned align)
+{
+ struct iov_iter i = *iter;
+ int nr_pages = 0;
+
+ while (iov_iter_count()) {
+ unsigned long uaddr = (unsigned long) i.iov->iov_base +
+ i.iov_offset;
+ unsigned long len = i.iov->iov_len - i.iov_offset;
+
+ if ((uaddr & align) || (len & align))
+ return -EINVAL;
+
+ /*
+* Overflow, abort
+*/
+ if (uaddr + len < uaddr)
+ return -EINVAL;
+
+ nr_pages += DIV_ROUND_UP(len + offset_in_page(uaddr),
+PAGE_SIZE);
+ iov_iter_advance(, len);
+ }
+
+ return nr_pages;
+}
+
/**
* bio_copy_user_iov - copy user data to bio
* @q: destination block queue
@@ -1163,24 +1190,9 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
unsigned int len = iter->count;
unsigned int offset = map_data ? map_data->offset & ~PAGE_MASK : 0;
- for (i = 0; i < iter->nr_segs; i++) {
- unsigned long uaddr;
- unsigned long end;
- unsigned long start;
-
- uaddr = (unsigned long) iter->iov[i].iov_base;
- end = (uaddr + iter->iov[i].iov_len + PAGE_SIZE - 1)
- >> PAGE_SHIFT;
- start = uaddr >> PAGE_SHIFT;
-
- /*
-* Overflow, abort
-*/
- if (end < start)
- return ERR_PTR(-EINVAL);
-
- nr_pages += end - start;
- }
+ nr_pages = iov_count_pages(iter, 0);
+ if (nr_pages < 0)
+ return ERR_PTR(nr_pages);
if (offset)
nr_pages++;
@@ -1292,25 +1304,9 @@ struct bio *bio_map_user_iov(struct request_queue *q,
struct iov_iter i;
struct iovec iov;
- iov_for_each(iov, i, *iter) {
- unsigned long uaddr = (unsigned long) iov.iov_base;
- unsigned long len = iov.iov_len;
- unsigned long end = (uaddr + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
- unsigned long start = uaddr >> PAGE_SHIFT;
-
- /*
-* Overflow, abort
-*/
- if (end < start)
- return ERR_PTR(-EINVAL);
-
- nr_pages += end - start;
- /*
-* buffer must be aligned to at least hardsector size for now
-*/
- if (uaddr & queue_dma_alignment(q))
- return ERR_PTR(-EINVAL);
- }
+ nr_pages = iov_count_pages(iter, queue_dma_alignment(q));
+ if (nr_pages < 0)
+ return ERR_PTR(nr_pages);
if (!nr_pages)
return ERR_PTR(-EINVAL);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary
On Thu, Apr 23, 2015 at 3:55 PM, Andy Lutomirski wrote: > > It's a matter of the ratio, right? One cycle of syscall overhead > saved is worth some number of context switch cycles added, and the > ratio probably varies by workload. Yeah. That said, I do think Peter is right that there are usually a *lot* more system calls than there are context switches, even if I guess you could come up with specific cases where that isn't true (eg in-kernel file servers etc that never actually go to user space). And the scheduler approach would have the benefit of not being in asm code, so we can more easily use things like static keys or alternative_asm() to make the overhead go away on CPU's that don't need it. We certainly _can_ do that in an *.S file too, but we don't have quite the same level of infrastructure help to do it. Adding some static key protected thing to switch_to() in arch/x86/kernel/process_64.c wouldn't seem too bad. And at that point, the only cost is a a single no-op on most CPU's (we still don't know _which_ AMD CPU's are affected, but I guess we could start off with all of them and see if we can get an exhaustive list some way). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] preparation for block layer simplification
I'd like to continue on Dongsu's effort to push Kent's block-stuff upstream.
This is a preparation series for simplifying block layer based on immutable
biovecs, a spin off of the v2 of simplifying patchset. [1] The original
goal of simplifying block layer was actually making generic_make_request()
accept arbitrarily sized bios, and pushing the splitting down to the
underlying drivers.
This patchset aims at cleaning up several parts that are independent of
core changes in the block layer. Doing that, it could be possible to
change block layer relatively easily without keeping up with many patches.
This patchset should be first applied prior to upcoming patchsets such as
"simplify block layer based on immutable biovecs." This patchset itself
should not bring any regression to end-users.
Changes in v3:
- rebase on top of Jen's bio-cnt branch
- drop patches 1 and 2 that were already upstream
- lib/iovec.c was gone, so move iov_count_pages to block/bio.c
Changes in v2:
- split up preparation patches from v1 into this separate series.
- In the patch 02, pass iov_iter by value to __bio_copy_iov(), and split
into read/write variants, as suggested by Christoph Hellwig.
- minor changes like writing more commit messages etc.
[1] https://lkml.org/lkml/2014/12/22/128
Kent Overstreet (4):
block: refactor iov_count_pages() from bio_{copy,map}_user_iov()
md/raid10: make sync_request_write() call bio_copy_data()
fs: make _submit_bh consistent with generic bio chaining
PM: submit bio in a sane way in cases without bio_chain
block/bio.c | 70
+-
drivers/md/raid10.c | 20 +---
fs/buffer.c | 4 ++--
kernel/power/block_io.c | 23 ++-
4 files changed, 58 insertions(+), 59 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 next] ocfs2: Reduce object size of mlog uses
On Wed, Apr 22, 2015 at 03:46:04PM -0700, Andrew Morton wrote:
> On Fri, 17 Apr 2015 00:17:50 -0700 Joe Perches wrote:
>
> > Using a function for __mlog_printk instead of a macro
> > reduces the object size of built-in.o more than 120KB, or
> > ~10% overall (x86-64 defconfig with all ocfs2 options)
> >
> > $ size fs/ocfs2/built-in.o*
> >textdata bss dec hex filename
> > 936255 118071 134408 1188734 12237e fs/ocfs2/built-in.o.new
> > 1064081 118071 134408 1316560 1416d0 fs/ocfs2/built-in.o.old
>
> It's a start.
>
> > --- a/fs/ocfs2/cluster/masklog.c
> > +++ b/fs/ocfs2/cluster/masklog.c
> > @@ -64,6 +64,23 @@ static ssize_t mlog_mask_store(u64 mask, const char
> > *buf, size_t count)
> > return count;
> > }
> >
> > +void __mlog_printk(const char *level, const char *func, int line,
> > + const char *fmt, ...)
> > +{
> > + struct va_format vaf;
> > + va_list args;
> > +
> > + va_start(args, fmt);
> > +
> > + vaf.fmt = fmt;
> > + vaf.va =
> > +
> > + printk("%s(%s,%u,%lu):%s:%d %pV",
> > + level, current->comm, task_pid_nr(current), __mlog_cpu_guess,
> > + func, line, );
> > +
> > + va_end(args);
> > +}
>
> Logging function-name and line-number was a bit weird. I wonder if
> anyone will mind if this is converted to file-n-line, as God intended.
> That will shrink rodata a bit, because number-of-files is a lot less
> than number-of-functions.
We can live with file-n-line.
> > - __mlog_printk(KERN_ERR, "ERROR: "fmt , ##args); \
> > + __mlog_printk(KERN_ERR, __func__, __LINE__, \
> > + "ERROR: " fmt, ##__VA_ARGS__);\
> > else if (__m & ML_NOTICE) \
> > - __mlog_printk(KERN_NOTICE, fmt , ##args); \
> > - else __mlog_printk(KERN_INFO, fmt , ##args);\
> > + __mlog_printk(KERN_NOTICE, __func__, __LINE__, \
> > + fmt, ##__VA_ARGS__); \
> > + else\
> > + __mlog_printk(KERN_INFO, __func__, __LINE__,\
> > + fmt, ##__VA_ARGS__); \
> > } \
> > } while (0)
> >
>
> I guess this patch is a step on the way - a 10% shrink is decent. But
> I believe that with full uninlining of the ocfs2 logging code we can
> shrink the filesystem's footprint by 50%.
>
> This code needs some pretty serious rework and rethink, perhaps
> involving a change to the emitted info. I was hoping one of the ocfs2
> developers would take the bait, but they're all in hiding.
If it functions the same and doesn't have a major performance change, I'm
pretty sure it'll be fine. We sometimes ask customers to enable some of the
debugging if they are having an issue. I would ask that it be tested
on a live system - a local fs, no cluster or cluster config required.
> If you feel like undertaking such a rotorooting then go wild - that should
> wake 'em up ;)
Ok, I've taken the bait :)
--Mark
--
Mark Fasheh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: git pull] drm for v4.1-rc1
On Thu, Apr 23, 2015 at 3:47 PM, Linus Torvalds wrote: > I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but > yes, if what this is all about is the magic video ROM at 0xc, then It's used in the PCI layer to say "Read from 0xc rather than the ROM BAR" and then ends up as a shorthand for "Was this the boot video device" in various places because we're bad at software. > There is no way to see that from the PCI device state, because as > mentioned, quite often the "ROM" is entirely fake, and is not just > some shadowed copy of a real underlying hardware ROM, but is > fundamentally just a RAM image decompressed from some other source and > then marked read-only. If only - nvidias used to rewrite their image at runtime. -- Matthew Garrett | matthew.garr...@coreos.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary
On Thu, Apr 23, 2015 at 3:52 PM, H. Peter Anvin wrote: > On 04/23/2015 03:38 PM, Andy Lutomirski wrote: >>> >>> Because there are way more sysrets than context switches, and Linux is >>> particularly sensitive to system call latency, by design. >> > > Just to clarify: why would Linux be more sensitive to system call by > design? It enables much simpler APIs and avoids hacks like sending down > a syscall task list (which was genuinely proposed at one point.) If > kernel entry/exit is too expensive, then the APIs get more complex > because they *have* to do everything in the smallest number of system calls. > It's a matter of the ratio, right? One cycle of syscall overhead saved is worth some number of context switch cycles added, and the ratio probably varies by workload. If we do syscall, two context switches, and sysret, then we wouldn't have been better off fixing it on sysret. But maybe most workloads still prefer the fixup on context switch. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Suspicious RCU usage in bridge with Linux v4.0-9362-g1fc149933fd4
On Thu, Apr 23, 2015 at 10:07 AM, Josh Boyer wrote:
> [ 29.382235] br0: port 1(tap0) entered forwarding state
>
> [ 29.382286] ===
> [ 29.382315] [ INFO: suspicious RCU usage. ]
> [ 29.382344] 4.1.0-0.rc0.git11.1.fc23.x86_64 #1 Not tainted
> [ 29.382380] ---
> [ 29.382409] net/bridge/br_private.h:626 suspicious
> rcu_dereference_check() usage!
> [ 29.382455]
>other info that might help us debug this:
>
> [ 29.382507]
>rcu_scheduler_active = 1, debug_locks = 0
> [ 29.382549] 2 locks held by swapper/0/0:
> [ 29.382576] #0: (((>forward_delay_timer))){+.-...}, at:
> [] call_timer_fn+0x5/0x4f0
> [ 29.382660] #1: (&(>lock)->rlock){+.-...}, at:
> [] br_forward_delay_timer_expired+0x31/0x140
> [bridge]
> [ 29.382754]
>stack backtrace:
> [ 29.382787] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.1.0-0.rc0.git11.1.fc23.x86_64 #1
> [ 29.382838] Hardware name: LENOVO 422916G/LENOVO, BIOS A1KT53AUS 04/07/2015
> [ 29.382882] 3ebfc20364115825 88003c48
> 81892d4b
> [ 29.382943] 81e124e0 88003c78
> 8110bcd7
> [ 29.383004] 8800785c9d00 88065485ac58 880c62002800
> 880c5fc88ac0
> [ 29.383065] Call Trace:
> [ 29.383084][] dump_stack+0x4c/0x65
> [ 29.383130] [] lockdep_rcu_suspicious+0xe7/0x120
> [ 29.383178] [] br_fill_ifinfo+0x4a9/0x6a0 [bridge]
> [ 29.383225] [] br_ifinfo_notify+0x11b/0x4b0 [bridge]
> [ 29.383271] [] ? br_hold_timer_expired+0x70/0x70
> [bridge]
> [ 29.383320] []
> br_forward_delay_timer_expired+0x58/0x140 [bridge]
> [ 29.383371] [] ? br_hold_timer_expired+0x70/0x70
> [bridge]
> [ 29.383416] [] call_timer_fn+0xc3/0x4f0
> [ 29.383454] [] ? call_timer_fn+0x5/0x4f0
> [ 29.383493] [] ? lock_release_holdtime.part.29+0xf/0x200
> [ 29.383541] [] ? br_hold_timer_expired+0x70/0x70
> [bridge]
> [ 29.383587] [] run_timer_softirq+0x244/0x490
> [ 29.383629] [] __do_softirq+0xec/0x670
> [ 29.383666] [] irq_exit+0x145/0x150
> [ 29.383703] [] smp_apic_timer_interrupt+0x46/0x60
> [ 29.383744] [] apic_timer_interrupt+0x73/0x80
> [ 29.383782][] ? cpuidle_enter_state+0x5f/0x2f0
> [ 29.383832] [] ? cpuidle_enter_state+0x5b/0x2f0
> [ 29.383873] [] cpuidle_enter+0x17/0x20
> [ 29.383908] [] cpu_startup_entry+0x36f/0x5f0
> [ 29.383949] [] rest_init+0x13d/0x150
> [ 29.383986] [] start_kernel+0x4d2/0x4f3
> [ 29.384023] [] ? early_idt_handlers+0x120/0x120
> [ 29.384064] [] x86_64_start_reservations+0x2a/0x2c
> [ 29.384105] [] x86_64_start_kernel+0x14a/0x16d
We are dereferencing a RCU pointer with rtnl assert, but in the timer context
we only have br->lock. It looks like we need to take RCU read lock on that path
rather than asserting rtnl lock.
Thanks for the report.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary
On 04/23/2015 03:38 PM, Andy Lutomirski wrote: >> >> Because there are way more sysrets than context switches, and Linux is >> particularly sensitive to system call latency, by design. > Just to clarify: why would Linux be more sensitive to system call by design? It enables much simpler APIs and avoids hacks like sending down a syscall task list (which was genuinely proposed at one point.) If kernel entry/exit is too expensive, then the APIs get more complex because they *have* to do everything in the smallest number of system calls. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/4] tracing: Add new hwlat_detector tracer
On Thu, Apr 23, 2015 at 1:21 PM, Thomas Gleixner wrote: > > But at least on the machines which have the event counter it would be > usefull to include that information as well. In fact, I'd argue that we should *not* do this odd magic latency measurement thing at all, exactly because Intel gave is the SMI counter, and it's much more likely to be useful in real life. The odd "stop machine and busy loop adn do magic" thing is a incredibly invasive hack that sane people will never enable at all, while the "add support for the hadrware we asked for and got" is a small thing that we can do on all modern Intel chips, and can be enabled by default because there is no downside. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
>>
>> int pcibios_add_device(struct pci_dev *dev)
>> {
>> if (dev-is-default-vga-device) {
>> dev->rom = 0xC;
>> dev->romlen = 0x2;
>> }
>
> I don't know what we want to do here. This is, at some level,
> fundamentally wrong - however, it also wouldn't surprise me if this is
> also the only copy of the video ROM we have on some UEFI systems,
> especially since I believe that Windows 7 still required that there be
> a legacy ROM it could use for bootloader modesetting on UEFI
> platforms. So simply making this conditional on BIOS may break
> existing machines. But if there *is* a ROM there then we should be
> able to id it from the usual video ROM signature?
I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
yes, if what this is all about is the magic video ROM at 0xc, then
(a) it should have nothing what-so-ever to do with the actual PCI
BAR, since it's been *ages* since people actually had an expansion rom
like that, and it's much more common that the video ROM comes as part
of the system BIOS on laptops etc.
(b) yes, the sane thing to do would be to just look for the ROM
signature, 0x55 0xaa at 2kB incrementing headers (and checking the
proper checksum too).
There is no way to see that from the PCI device state, because as
mentioned, quite often the "ROM" is entirely fake, and is not just
some shadowed copy of a real underlying hardware ROM, but is
fundamentally just a RAM image decompressed from some other source and
then marked read-only.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/hugetlb: reduce arch dependent code about huge_pmd_unshare
On Thu, 23 Apr 2015 22:26:18 + "Luck, Tony" wrote: > > Memory fails me. Why do some architectures (arm, arm64, x86_64) want > > huge_pmd_[un]share() while other architectures (ia64, tile, mips, > > powerpc, metag, sh, s390) do not? > > Potentially laziness/ignorance-of-feature? It looks like this feature > started on x86_64 and then spread > to arm*. Yes. In 3212b535f200c85b5a6 Steve Capper (ARM person) hoisted the code out of x86 into generic, then made arm use it. We're not (I'm not) very good about letting arch people know about such things. I wonder how to fix that; does linux-arch work? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
