Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Christoph Hellwig writes: > This doesn't address any or the previous points: > > - common implementation instead of the godawful boilerplate code >(and we even fixed most of this for Posix ACL by now, so even less >reason to do the same crap again!) We already do that with richacl. Richacl already have most of the details implemented in common code. Comparing to recent posix acl changes we could still simplify chmod and xattr bits. I will do that in the next update. > - common data structure with Posix ACLs > Can you explain this ?. Why do we want to do that ? > And of course no real explanation why we need the braindead access/deny > scheme at how it will get properly integrated with the system. > > So in this for a clear NAK. -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz,
On Sat, Apr 26, 2014 at 4:33 AM, Tomasz Figa wrote:
> Hi Vivek,
>
>
> On 22.04.2014 10:03, Vivek Gautam wrote:
>>
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt| 40 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 629
>>
>> 4 files changed, 681 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index b422e38..51efe4c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -114,3 +114,43 @@ Example:
>> compatible = "samsung,exynos-sataphy-i2c";
>> reg = <0x38>;
>> };
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
[snip]
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 3bb05f1..8a5d2b4 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -166,4 +166,15 @@ config PHY_XGENE
>> help
>> This option enables support for APM X-Gene SoC multi-purpose
>> PHY.
>>
>> +config PHY_EXYNOS5_USBDRD
>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>> + depends on ARCH_EXYNOS5 && OF
>> + depends on HAS_IOMEM
>> + select GENERIC_PHY
>> + select MFD_SYSCON
>> + help
>> + Enable USB DRD PHY support for Exynos 5 SoC series.
>> + This driver provides PHY interface for USB 3.0 DRD controller
>> + present on Exynos5 SoC series.
>> +
>
>
> I think you should probably keep the entries sorted, so this one should be
> somewhere around other EXYNOS PHYs.
Right, thanks for pointing this out.
Will move this along with other PHY_EXYNOS USB* configs.
>
>
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 2faf78e..31baa0c 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) +=
>> phy-exynos4210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>
>
> Ditto.
Ok
>
>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> new file mode 100644
>> index 000..89d7ae8
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>> @@ -0,0 +1,629 @@
>> +/*
>> + * Samsung EXYNOS5 SoC series USB DRD PHY driver
>> + *
>> + * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
>> + *
>> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
>> + * Author: Vivek Gautam
>> + *
[snip]
>> + } phys[EXYNOS5_DRDPHYS_NUM];
>> + unsigned int extrefclk;
>> + struct clk *ref_clk;
>> + unsigned long ref_rate;
>> +};
>> +
>> +#define to_usbdrd_phy(inst) \
>> + container_of((inst), struct exynos5_usbdrd_phy, \
>> +phys[(inst)->index]);
>
>
> This should be made a static inline to enforce type checking.
Ok, will make this as static inline routine, so that compiler don't
skip type checking.
>
>
>> +
>> +/*
>> + * exynos5_rate_to_clk() converts the supplied clock rate to the value
>> that
>> + * can be written to the phy register.
>> + */
>> +static unsigned int exynos5_rate_to_clk(unsigned long rate)
>> +{
>> + unsigned int clksel;
>> +
>> + /* EXYNOS5_FSEL_MASK */
>> +
>> + switch (rate) {
>> + case 9600 * KHZ:
>> + clksel = EXYNOS5_FSEL_9MHZ6;
>> + break;
>> + case 10 * MHZ:
>> + clksel = EXYNOS5_FSEL_10MHZ;
>> + break;
>> + case 12 * MHZ:
>> + clksel = EXYNOS5_FSEL_12MHZ;
>> + break;
>> + case 19200 * KHZ:
>> + clksel = EXYNOS5_FSEL_19MHZ2;
>> + break;
>> + case 20 * MHZ:
>> + clksel = EXYNOS5_FSEL_20MHZ;
>> + break;
>> + case 24 * MHZ:
>> + clksel = EXYNOS5_FSEL_24MHZ;
>> + break;
>> + case 50 * MHZ:
>> + clksel = EXYNOS5_FSEL_50MHZ;
>> + break;
>> + default:
>> + clksel = -EINVAL;
>
>
> Based on clksel (and return value of this function) being unsigned I don't
> think this is a good idea. You should probably adapt the approach
[PATCH v2 1/1] Driver for Beckhoff CX5020 EtherCAT master module.
Changes since v1:
* added endianess annotation to descriptors' structures
* killed checkpath warnings about string literals being split into multiple
lines
>88<
This driver adds support for EtherCAT master module located on CCAT
FPGA found on Beckhoff CX series industrail PCs. The driver exposes
EtherCAT master as an ethernet interface.
EtherCAT is a filedbus protocol defined on top of ethernet and Beckhoff
CX5020 PCs come with built-in EtherCAT master module located on a FPGA,
which in turn is connected to a PCI bus.
Signed-off-by: Dariusz Marcinkiewicz
---
drivers/net/ethernet/Kconfig | 11 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/ec_bh.c | 768 +
3 files changed, 780 insertions(+)
create mode 100644 drivers/net/ethernet/ec_bh.c
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 39b26fe..a81611d 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -35,6 +35,17 @@ source "drivers/net/ethernet/calxeda/Kconfig"
source "drivers/net/ethernet/chelsio/Kconfig"
source "drivers/net/ethernet/cirrus/Kconfig"
source "drivers/net/ethernet/cisco/Kconfig"
+
+config CX_ECAT
+ tristate "Beckhoff CX5020 EtherCAT master support"
+ ---help---
+ Driver for EtherCAT master module located on CCAT FPGA
+ that can be found on Beckhoff CX5020, and possibly other of CX
+ Beckhoff CX series industrial PCs.
+
+ To compile this driver as a module, choose M here. The module
+ will be called ec_bh.
+
source "drivers/net/ethernet/davicom/Kconfig"
config DNET
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 545d0b3..1712c87 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_CALXEDA_XGMAC) += calxeda/
obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
obj-$(CONFIG_NET_VENDOR_CIRRUS) += cirrus/
obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
+obj-$(CONFIG_CX_ECAT) += ec_bh.o
obj-$(CONFIG_DM9000) += davicom/
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_NET_VENDOR_DEC) += dec/
diff --git a/drivers/net/ethernet/ec_bh.c b/drivers/net/ethernet/ec_bh.c
new file mode 100644
index 000..cc63af4
--- /dev/null
+++ b/drivers/net/ethernet/ec_bh.c
@@ -0,0 +1,768 @@
+/*
+ * drivers/net/ethernet/beckhoff/ec_bh.c
+ *
+ * Copyright (C) 2014 Darek Marcinkiewicz
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+/* This is a driver for EtherCAT master module present on CCAT FPGA.
+ * Those can be found on Bechhoff CX50xx industrial PCs.
+ */
+
+#if 0
+#define DEBUG
+#endif
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TIMER_INTERVAL_NSEC2
+
+#define INFO_BLOCK_SIZE0x10
+#define INFO_BLOCK_TYPE0x0
+#define INFO_BLOCK_REV 0x2
+#define INFO_BLOCK_BLK_CNT 0x4
+#define INFO_BLOCK_TX_CHAN 0x4
+#define INFO_BLOCK_RX_CHAN 0x5
+#define INFO_BLOCK_OFFSET 0x8
+
+#define EC_MII_OFFSET 0x4
+#define EC_FIFO_OFFSET 0x8
+#define EC_MAC_OFFSET 0xc
+
+#define MAC_FRAME_ERR_CNT 0x0
+#define MAC_RX_ERR_CNT 0x1
+#define MAC_CRC_ERR_CNT0x2
+#define MAC_LNK_LST_ERR_CNT0x3
+#define MAC_TX_FRAME_CNT 0x10
+#define MAC_RX_FRAME_CNT 0x14
+#define MAC_TX_FIFO_LVL0x20
+#define MAC_DROPPED_FRMS 0x28
+#define MAC_CONNECTED_CCAT_FLAG0x78
+
+#define MII_MAC_ADDR 0x8
+#define MII_MAC_FILT_FLAG 0xe
+#define MII_LINK_STATUS0xf
+
+#define FIFO_TX_REG0x0
+#define FIFO_TX_RESET 0x8
+#define FIFO_RX_REG0x10
+#define FIFO_RX_RESET 0x18
+
+#define DMA_CHAN_OFFSET0x1000
+#define DMA_CHAN_SIZE 0x8
+
+static struct pci_device_id ids[] = {
+ { PCI_DEVICE(0x15ec, 0x5000), },
+ { 0, }
+};
+MODULE_DEVICE_TABLE(pci, ids);
+
+struct rx_header {
+#define RXHDR_NEXT_ADDR_MASK 0xffu
+#define RXHDR_NEXT_VALID (1u << 31)
+ __le32 next;
+#define RXHDR_NEXT_RECV_FLAG 0x1
+ __le32 recv;
+#define RXHDR_LEN_MASK 0xfffu
+ __le16 len;
+ __le16 port;
+ __le32 reserved;
+ u8 timestamp[8];
+} __packed;
+
+struct rx_desc {
+ struct rx_header header;
+#define RX_PAYLOAD_SIZE0x7e8
+ u8 data[RX_PAYLOAD_SIZE];
+} __packed;
+
+struct
[PATCH 2/2] Regulators: TPS65917: Add Regulator driver for TPS65917 PMIC
This patch adds support for TPS65917 PMIC regulators.
The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Keerthy
---
drivers/regulator/Kconfig | 12 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps65917-regulator.c | 903
3 files changed, 916 insertions(+)
create mode 100644 drivers/regulator/tps65917-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..5ddb220 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -384,6 +384,18 @@ config REGULATOR_PALMAS
on the muxing. This is handled automatically in the driver by
reading the mux info from OTP.
+config REGULATOR_TPS65917
+ tristate "TI TPS65917 PMIC Regulators"
+ depends on MFD_TPS65917
+ help
+ If you wish to control the regulators on the TPS65917 series of
+ chips say Y here. This will enable support for all the software
+ controllable SMPS/LDO regulators.
+
+ The regulators available on TPS65917 series chips vary depending
+ on the muxing. This is handled automatically in the driver by
+ reading the mux info from OTP.
+
config REGULATOR_PCAP
tristate "Motorola PCAP2 regulator driver"
depends on EZX_PCAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..381dfd3 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65917) += tps65917-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
diff --git a/drivers/regulator/tps65917-regulator.c
b/drivers/regulator/tps65917-regulator.c
new file mode 100644
index 000..be94a7a
--- /dev/null
+++ b/drivers/regulator/tps65917-regulator.c
@@ -0,0 +1,903 @@
+/*
+ * Driver for Regulator part of TPS65917 PMIC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct regs_info {
+ char*name;
+ char*sname;
+ u8 vsel_addr;
+ u8 ctrl_addr;
+ int sleep_id;
+};
+
+static const struct regs_info tps65917_regs_info[] = {
+ {
+ .name = "SMPS1",
+ .sname = "smps1-in",
+ .vsel_addr = TPS65917_SMPS1_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+ },
+ {
+ .name = "SMPS2",
+ .sname = "smps2-in",
+ .vsel_addr = TPS65917_SMPS2_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS2_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+ },
+ {
+ .name = "SMPS3",
+ .sname = "smps3-in",
+ .vsel_addr = TPS65917_SMPS3_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS3_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+ },
+ {
+ .name = "SMPS4",
+ .sname = "smps4-in",
+ .vsel_addr = TPS65917_SMPS4_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS4_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
+ },
+ {
+ .name = "SMPS5",
+ .sname = "smps5-in",
+ .vsel_addr = TPS65917_SMPS5_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS5_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
+ },
+ {
+ .name = "LDO1",
+ .sname = "ldo1-in",
+ .vsel_addr = TPS65917_LDO1_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO1,
+
[PATCH 0/2] TPS65917: Drivers for TPS65917 PMIC
The TPS65917 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - GPADC. - Over Temperature warning and Shut down. This patch series adds support for TPS65917 mfd device. At this time only the regulator functionality is made available. The closest drivers are PALMAS series drivers. The register set is changed. Bit-field defenitions are changed. Hence based on the PALMAS drivers and created a new set of drivers with code changes as required. The patches are boot tested on DRA7-EVM. Keerthy (2): MFD: TPS65917: Add driver for the TPS65917 PMIC Regulators: TPS65917: Add Regulator driver for TPS65917 PMIC drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile |1 + drivers/mfd/tps65917.c | 542 drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/tps65917-regulator.c | 903 +++ include/linux/mfd/tps65917.h | 1508 7 files changed, 2977 insertions(+) create mode 100644 drivers/mfd/tps65917.c create mode 100644 drivers/regulator/tps65917-regulator.c create mode 100644 include/linux/mfd/tps65917.h -- 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 -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner writes: > On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: >> Hi >> >> As per LSF/MM summit discussion I am reposting the richacl patchset for >> upstream inclusion. The patchset includes minimal changes required to >> implement >> a new acl model similar to NFSv4 ACL. The acl model selection is based on >> file system feature flag. >> >> The following set of patches implements VFS and ext4 changes needed to >> implement >> a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, >> extended by file masks to fit into the standard POSIX file permission model. >> They are designed to work seamlessly locally as well as across the NFSv4 and >> CIFS/SMB2 network file system protocols. >> >> A user-space utility for displaying and changing richacls is available at [1] >> (a number of examples can be found at >> http://acl.bestbits.at/richacl/examples.html). >> >> [1] git://github.com/kvaneesh/richacl-tools.git master >> >> To test richacl on ext4, create the file sytem with richacl feature flag >> (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled >> using mount option "acl" will switch to using richacl instead of posixacl. > > No mount options, please. The ACL configuration needs to be > determined solely by the superblock feature bit - we cannot support > filesystems with mixed ACL types, and that's what this mount option > does. For ext4 since acls are enabled by default we really don't need to speciy -o acl in mount. What i meant by above is that using "acl/noacl" mount option will now enabe/disable POSIX or RICHacl based on the superblock feature bit. > >> More details regarding richacl can be found at >> http://acl.bestbits.at/richacl/ >> >> Previous posting of the patchset can be found at: >> http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com >> "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" >> >> The complete patchset can also be found at: >> https://github.com/kvaneesh/linux/commits/richacl-for-upstream > > Where are the tests? We need comprehensive coverage in xfstests so > we can validate that it works the way it is supposed to and that we > don't break it in future, and that all filesystems behave the same > way > https://github.com/kvaneesh/richacl-tools/tree/master/test -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 usb-gadget tree with the usb tree
Hi Felipe,
Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/phy/phy-mv-u3d-usb.c between commit 543cab640279 ("usb: phy:
mv_u3d: Remove usb phy driver for mv_u3d") from the usb tree and commit
041832565e40 ("usb: phy: mv-u3d: switch over to writel/readl") from the
usb-gadget tree.
I fixed it up (the former removes the file, so I did that) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpzi6j4N6KKP.pgp
Description: PGP signature
Re: [PATCH] rwsem: Support optimistic spinning
ping?
On Tue, 2014-04-22 at 15:19 -0700, Davidlohr Bueso wrote:
> We have reached the point where our mutexes are quite fine tuned
> for a number of situations. This includes the use of heuristics
> and optimistic spinning, based on MCS locking techniques.
>
> Exclusive ownership of read-write semaphores are, conceptually,
> just about the same as mutexes, making them close cousins. To
> this end we need to make them both perform similarly, and
> right now, rwsems are simply not up to it. This was discovered
> by both reverting commit 4fc3f1d6 (mm/rmap, migration: Make
> rmap_walk_anon() and try_to_unmap_anon() more scalable) and
> similarly, converting some other mutexes (ie: i_mmap_mutex) to
> rwsems. This creates a situation where users have to choose
> between a rwsem and mutex taking into account this important
> performance difference. Specifically, biggest difference between
> both locks is when we fail to acquire a mutex in the fastpath,
> optimistic spinning comes in to play and we can avoid a large
> amount of unnecessary sleeping and overhead of moving tasks in
> and out of wait queue. Rwsems do not have such logic.
>
> This patch, based on the work from Tim Chen and I, adds support
> for write-side optimistic spinning when the lock is contended.
> It also includes support for the recently added cancelable MCS
> locking for adaptive spinning.
>
> Allowing optimistic spinning before putting the writer on the wait
> queue reduces wait queue contention and provided greater chance
> for the rwsem to get acquired. With these changes, rwsem is on par
> with mutex. The performance benefits can be seen on a number of
> workloads. For instance, on a 8 socket, 80 core 64bit Westmere box,
> aim7 shows the following improvements in throughput:
>
> +--+-+-+
> | Workload | throughput-increase | number of users |
> +--+-+-+
> | alltests | 20% | >1000 |
> | custom | 27%, 60%| 10-100, >1000 |
> | high_systime | 36%, 30%| >100, >1000 |
> | shared | 58%, 29%| 10-100, >1000 |
> +--+-+-+
>
> There was also improvement on smaller systems, such as a quad-core
> x86-64 laptop running a 30Gb PostgreSQL (pgbench) workload for up
> to +60% in throughput for over 50 clients. Additionally, benefits
> were also noticed in exim (mail server) workloads. Furthermore, no
> performance regression have been seen at all.
>
> Signed-off-by: Davidlohr Bueso
> Signed-off-by: Tim Chen
> ---
> include/linux/rwsem.h | 9 +-
> kernel/locking/rwsem-xadd.c | 213
> +++-
> kernel/locking/rwsem.c | 31 ++-
> 3 files changed, 231 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> index 03f3b05..6f992e2 100644
> --- a/include/linux/rwsem.h
> +++ b/include/linux/rwsem.h
> @@ -16,6 +16,7 @@
>
> #include
>
> +struct optimistic_spin_queue;
> struct rw_semaphore;
>
> #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
> @@ -26,6 +27,10 @@ struct rw_semaphore {
> longcount;
> raw_spinlock_t wait_lock;
> struct list_headwait_list;
> +#ifdef CONFIG_SMP
> + struct task_struct *owner; /* write owner */
> + struct optimistic_spin_queue *osq; /* spinner MCS lock */
> +#endif
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif
> @@ -58,7 +63,9 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
> #define __RWSEM_INITIALIZER(name)\
> { RWSEM_UNLOCKED_VALUE, \
> __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
> - LIST_HEAD_INIT((name).wait_list) \
> + LIST_HEAD_INIT((name).wait_list), \
> + NULL, /* owner */ \
> + NULL /* mcs lock */ \
> __RWSEM_DEP_MAP_INIT(name) }
>
> #define DECLARE_RWSEM(name) \
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 1d66e08..b6a67fe 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -5,12 +5,18 @@
> *
> * Writer lock-stealing by Alex Shi
> * and Michel Lespinasse
> + *
> + * Optimistic spinning by Tim Chen
> + * and Davidlohr Bueso . Based on mutexes.
> */
> #include
> #include
> #include
> +#include
> #include
>
> +#include "mcs_spinlock.h"
> +
> /*
> * Initialize an rwsem:
> */
> @@ -27,6 +33,10 @@ void __init_rwsem(struct rw_semaphore *sem, const char
> *name,
> sem->count = RWSEM_UNLOCKED_VALUE;
> raw_spin_lock_init(>wait_lock);
> INIT_LIST_HEAD(>wait_list);
> +#ifdef CONFIG_SMP
> + sem->owner = NULL;
> + sem->osq = NULL;
> +#endif
> }
>
> EXPORT_SYMBOL(__init_rwsem);
> @@
Re: [ANNOUNCE] 3.14-rt1
Hi Nicholas, On Sat, 2014-04-26 at 15:58 +0200, Mike Galbraith wrote: > On Sat, 2014-04-26 at 10:38 +0200, Mike Galbraith wrote: > > On Fri, 2014-04-25 at 09:40 +0200, Mike Galbraith wrote: > > > > > Hotplug can still deadlock in rt trees too, and will if you beat it > > > hard. > > > > Box actually deadlocks like so. > > ... > > 3.12-rt looks a bit busted migrate_disable/enable() wise. > > /me eyeballs 3.10-rt (looks better), confirms 3.10-rt hotplug works, > swipes working code, confirms 3.12-rt now works. Yup, that was it. My boxen, including 64 core DL980 that ran hotplug stress for 3 hours yesterday with pre-pushdown rwlocks, say the migrate_disable/enable pushdown patches are very definitely busted. Instead of whacking selective bits, as I did to verify that the rwlock changes were indeed causing hotplug stress deadlock woes, I'm eyeballing the lot, twiddling primitives to look like I think they should, after which I'll let my boxen express their opinions of the result. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Add support for flag status register on Micron chips.
On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote: > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote: > > > > > the drivers may fills this hook itself, so the code should like this: > > > > >-- > > > > > > > > > > if ((info->flags & USE_FSR) && > > > > > > > > > > nor->wait_till_ready == spi_nor_wait_till_fsr_ready) > > > > > > > > > > nor->wait_till_ready = spi_nor_wait_till_fsr_ready; > > > > > > > > > >-- > > > > > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and > > > > the driver compete for a function pointer here ? I guess one should > > > > have precedence in some way then ... and also, they should be two > > > > different pointers, where the subsystem decides which to use. > > > > > > the subsystem do not decides which one to use, the driver decides which > > > one to use. > > > > > > If driver has its own @wait_till_ready , it means the driver knows the > > > feature, and has implemented it in its own @wait_till_ready. > > > > > > If the driver does not fill any wait_till_ready, it means the driver > > > will use the default @wait_till_ready. We can treat the > > > spi_nor_wait_till_fsr_ready as a default hook too. > > > > I see the driver overwriting a hook previously set by the subsystem. This > > not sure ;) > > The driver set the hooks before the subsystem set these hooks. > > If the driver has already set the @wait_till_ready hook before it calls > the spi_nor_scan, the subsystem will not set the hook anymore. > > Please see the spi_nor_check(). Two things competing over the same pointer looks misdesigned to me. I will need to dig into this one more time ... Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] KVM: nVMX: additional checks on vmxon region
Currently, the vmxon region isn't used in the nested case.
However, according to the spec, the vmxon instruction performs
additional sanity checks on this region and the associated
pointer. Modify emulated vmxon to better adhere to the spec
requirements
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c18fe9a4..d5342c7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -354,6 +354,7 @@ struct vmcs02_list {
struct nested_vmx {
/* Has the level1 guest done vmxon? */
bool vmxon;
+ gpa_t vmxon_ptr;
/* The guest-physical address of the current VMCS L1 keeps for L2 */
gpa_t current_vmptr;
@@ -5840,9 +5841,19 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
struct kvm_segment cs;
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct vmcs *shadow_vmcs;
+ gva_t gva;
+ gpa_t vmptr;
+ struct x86_exception e;
+ struct page *page;
+
const u64 VMXON_NEEDED_FEATURES = FEATURE_CONTROL_LOCKED
| FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
+ /* Guest physical Address Width */
+ struct kvm_cpuid_entry2 *best =
+ kvm_find_cpuid_entry(vcpu, 0x8008, 0);
+
+
/* The Intel VMX Instruction Reference lists a bunch of bits that
* are prerequisite to running VMXON, most notably cr4.VMXE must be
* set to 1 (see vmx_set_cr4() for when we allow the guest to set this).
@@ -5865,6 +5876,46 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
kvm_inject_gp(vcpu, 0);
return 1;
}
+
+ if (get_vmx_mem_address(vcpu, vmcs_readl(EXIT_QUALIFICATION),
+ vmcs_read32(VMX_INSTRUCTION_INFO), ))
+ return 1;
+
+ if (kvm_read_guest_virt(>arch.emulate_ctxt, gva, ,
+ sizeof(vmptr), )) {
+ kvm_inject_page_fault(vcpu, );
+ return 1;
+ }
+
+ /* Don't bailout if best is NULL */
+ WARN_ON(!best);
+
+ /*
+* SDM 3: 24.11.5
+* VMXON pointer must be 4KB aligned
+* VMXON pointer must not set any bits beyond processor's
+* physical address width
+* The first 4 bytes of VMXON region contain the supported
+* VMCS revision identifier
+*
+* Note - IA32_VMX_BASIC[48] will never be 1 for the nested case;
+* which replaces physical address width with 32
+*/
+ if (!IS_ALIGNED(vmptr, PAGE_SIZE) || (best &&
+ (vmptr >> (best->eax & 0xff {
+ nested_vmx_failInvalid(vcpu);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
+ page = nested_get_page(vcpu, vmptr);
+ if ((page == NULL) || ((*(u32 *)kmap(page) != VMCS12_REVISION))) {
+ nested_vmx_failInvalid(vcpu);
+ kunmap(page);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmx->nested.vmxon) {
nested_vmx_failValid(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
skip_emulated_instruction(vcpu);
@@ -5896,9 +5947,11 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
vmx->nested.vmxon = true;
+ vmx->nested.vmxon_ptr = vmptr;
skip_emulated_instruction(vcpu);
nested_vmx_succeed(vcpu);
+ kunmap(page);
return 1;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] KVM: nVMX: fail on invalid vmclear/vmptrld pointer
The spec mandates that if the vmptrld or vmclear
address is equal to the vmxon region pointer, the
instruction should fail with error "VMPTRLD with
VMXON pointer" or "VMCLEAR with VMXON pointer"
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d5342c7..8864fa1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6069,6 +6069,12 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
return 1;
}
+ if (vmptr == vmx->nested.vmxon_ptr) {
+ nested_vmx_failValid(vcpu, VMXERR_VMCLEAR_VMXON_POINTER);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmptr == vmx->nested.current_vmptr) {
nested_release_vmcs12(vmx);
vmx->nested.current_vmptr = -1ull;
@@ -6412,6 +6418,12 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
return 1;
}
+ if (vmptr == vmx->nested.vmxon_ptr) {
+ nested_vmx_failValid(vcpu, VMXERR_VMPTRLD_VMXON_POINTER);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmx->nested.current_vmptr != vmptr) {
struct vmcs12 *new_vmcs12;
struct page *page;
--
1.8.3.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 1/3] KVM: nVMX: rearrange get_vmx_mem_address
handle_vmon will call this function to get the vmxon region
pointer in the next patch
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 106 ++---
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1f68c58..c18fe9a4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5775,6 +5775,59 @@ static enum hrtimer_restart
vmx_preemption_timer_fn(struct hrtimer *timer)
}
/*
+ * Decode the memory-address operand of a vmx instruction, as recorded on an
+ * exit caused by such an instruction (run by a guest hypervisor).
+ * On success, returns 0. When the operand is invalid, returns 1 and throws
+ * #UD or #GP.
+ */
+static int get_vmx_mem_address(struct kvm_vcpu *vcpu,
+unsigned long exit_qualification,
+u32 vmx_instruction_info, gva_t *ret)
+{
+ /*
+* According to Vol. 3B, "Information for VM Exits Due to Instruction
+* Execution", on an exit, vmx_instruction_info holds most of the
+* addressing components of the operand. Only the displacement part
+* is put in exit_qualification (see 3B, "Basic VM-Exit Information").
+* For how an actual address is calculated from all these components,
+* refer to Vol. 1, "Operand Addressing".
+*/
+ int scaling = vmx_instruction_info & 3;
+ int addr_size = (vmx_instruction_info >> 7) & 7;
+ bool is_reg = vmx_instruction_info & (1u << 10);
+ int seg_reg = (vmx_instruction_info >> 15) & 7;
+ int index_reg = (vmx_instruction_info >> 18) & 0xf;
+ bool index_is_valid = !(vmx_instruction_info & (1u << 22));
+ int base_reg = (vmx_instruction_info >> 23) & 0xf;
+ bool base_is_valid = !(vmx_instruction_info & (1u << 27));
+
+ if (is_reg) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
+
+ /* Addr = segment_base + offset */
+ /* offset = base + [index * scale] + displacement */
+ *ret = vmx_get_segment_base(vcpu, seg_reg);
+ if (base_is_valid)
+ *ret += kvm_register_read(vcpu, base_reg);
+ if (index_is_valid)
+ *ret += kvm_register_read(vcpu, index_reg)<> 7) & 7;
- bool is_reg = vmx_instruction_info & (1u << 10);
- int seg_reg = (vmx_instruction_info >> 15) & 7;
- int index_reg = (vmx_instruction_info >> 18) & 0xf;
- bool index_is_valid = !(vmx_instruction_info & (1u << 22));
- int base_reg = (vmx_instruction_info >> 23) & 0xf;
- bool base_is_valid = !(vmx_instruction_info & (1u << 27));
-
- if (is_reg) {
- kvm_queue_exception(vcpu, UD_VECTOR);
- return 1;
- }
-
- /* Addr = segment_base + offset */
- /* offset = base + [index * scale] + displacement */
- *ret = vmx_get_segment_base(vcpu, seg_reg);
- if (base_is_valid)
- *ret += kvm_register_read(vcpu, base_reg);
- if (index_is_valid)
- *ret += kvm_register_read(vcpu, index_reg)
[PATCH 0/3] Emulate VMXON region correctly
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521 The vmxon region is unused by nvmx, but adding these checks are probably harmless and may detect buggy L1 hypervisors in the future! Bandan Das (3): KVM: nVMX: rearrange get_vmx_mem_address KVM: nVMX: additional checks on vmxon region KVM: nVMX: fail on invalid vmclear/vmptrld pointer arch/x86/kvm/vmx.c | 171 - 1 file changed, 118 insertions(+), 53 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
On 04/27/2014 09:47 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote: The catalog version number was changed from a be32 (with proceeding 32bits of padding) to a be64, update the code to treat it as a be64 Signed-off-by: Cody P Schafer -- Have you tested this ? It doesn't build for me: arch/powerpc/perf/hv-24x7.c: In function 'catalog_read': arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Werror=format] cc1: all warnings being treated as errors I have, and I wasn't initially sure how I managed to miss that warning-as-error. On examination: My config (for some reason) has CONFIG_PPC_DISABLE_WERROR=y set (probably because it's a variation of a distro config). Must have been piping the warnings to a file and forgotten to check the file. I'll fix that up in my tree. 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 0/4] acerhdf/thermal: adding new models and appropriate governor
Hi,
On Mon, Apr 28, 2014 at 01:13:19AM +0200, Peter Feuerer wrote:
> Hi,
>
> Andreas Mohr writes:
>
> > { "Acer", "AOA1", _reg_map_AOAxxx_Acer_orig_version },
> >
> > Of course you then have the indirection of device name <-> specific
> > register values (quote: "really ugly and hard to read"?),
> > but IMHO that's ok since normally you wouldn't be too focused
> > on looking up register values (...right!?).
> >
> > And if the next interface-breaking config change came along,
> > you'd otherwise have to add yet another register index pair...
> > (at which point some 100+ char line monsters
> > would be breathing down our neck...)
>
> I think we have been discussing this solution a year ago or something and
> seems like it is really time to implement it. As I wrote in the other mail
> to Boris, I'd like to just do a minor modification for now and then when
> those 4 patches have been applied concentrate on implementing the splitted
> structs.
Yup, to get things out of the way now :)
[[BTW your mail environment seems configured to have trailing blanks -
might want to "optimize" that away...]]
> > - depends on THERMAL && ACPI
> > + depends on THERMAL && ACPI && THERMAL_GOV_BANG_BANG
> > Do we actively depend on THERMAL (code-wise, I mean?) Or is it now an
> > implicit dependency given that we request THERMAL_GOV_BANG_BANG? If
> > implicit, then THERMAL probably ought to be removed. But if we use
> > generic thermal APIs (which we probably do), then of course we do have
> > that dependency
>
> There's an implicit dependency due to the request of THERMAL_GOV_BANG_BANG, so
> yes, we could remove THERMAL here.
ok. Does not seem too risky, and reduces the need for future updates.
> > "used to force thermal" --> misleading ("we used to do this, but it's
> > bad so we better do that").
> >
> > "intended to"? "established to"? "added to"? or some simpler wording?
>
> What do you think about this wording:
> /*
> * this struct is used to instruct thermal layer to use bang_bang instead of
> * default governor for acerhdf
> */
Nicely detailed.
About the _t typedef: it's said that use of "_t" is undesirable anyway
due to being reserved for POSIX.
https://en.wikipedia.org/wiki/Typedef
http://stackoverflow.com/questions/1186072/naming-scheme-for-typedefs
As an alternative using a full "_type" is ok right?
(that's what I've been doing...)
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote:
> The catalog version number was changed from a be32 (with proceeding
> 32bits of padding) to a be64, update the code to treat it as a be64
>
> Signed-off-by: Cody P Schafer
> --
Have you tested this ?
It doesn't build for me:
arch/powerpc/perf/hv-24x7.c: In function 'catalog_read':
arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type
'int', but argument 2 has type 'uint64_t' [-Werror=format]
cc1: all warnings being treated as errors
I'll fix that up in my tree.
Cheers,
Ben.
> arch/powerpc/perf/hv-24x7.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 95a67f8..9d4badc 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -171,7 +171,7 @@ static unsigned long h_get_24x7_catalog_page_(unsigned
> long phys_4096,
> }
>
> static unsigned long h_get_24x7_catalog_page(char page[],
> - u32 version, u32 index)
> + u64 version, u32 index)
> {
> return h_get_24x7_catalog_page_(virt_to_phys(page),
> version, index);
> @@ -185,7 +185,7 @@ static ssize_t catalog_read(struct file *filp, struct
> kobject *kobj,
> ssize_t ret = 0;
> size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
> loff_t page_offset = 0;
> - uint32_t catalog_version_num = 0;
> + uint64_t catalog_version_num = 0;
> void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
> struct hv_24x7_catalog_page_0 *page_0 = page;
> if (!page)
> @@ -197,7 +197,7 @@ static ssize_t catalog_read(struct file *filp, struct
> kobject *kobj,
> goto e_free;
> }
>
> - catalog_version_num = be32_to_cpu(page_0->version);
> + catalog_version_num = be64_to_cpu(page_0->version);
> catalog_page_len = be32_to_cpu(page_0->length);
> catalog_len = catalog_page_len * 4096;
>
> @@ -255,7 +255,7 @@ e_free:
> \
> static DEVICE_ATTR_RO(_name)
>
> PAGE_0_ATTR(catalog_version, "%lld\n",
> - (unsigned long long)be32_to_cpu(page_0->version));
> + (unsigned long long)be64_to_cpu(page_0->version));
> PAGE_0_ATTR(catalog_len, "%lld\n",
> (unsigned long long)be32_to_cpu(page_0->length) * 4096);
> static BIN_ATTR_RO(catalog, 0/* real length varies */);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: samsung: Add sound card driver for Snow board
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
There are some other variants for Snow board which have MAX98090
audio codec. Hence support for MAX98090 is also added to this
driver.
Signed-off-by: Tushar Behera
---
Changes for V3:
1. Updated documentation (I2S0 -> I2S)
2. Removed 'Capture' DAI and renamed 'Playback' DAI as 'Primary'.
3. Updated patch subject to match sub-system naming style.
Changes for V2:
Addressed various comments from Mark Brown.
1. Moved DAIFMT flags to dai_link. Removed snd_soc_dai_set_fmt calls.
2. Removed BCLK settings.
3. Moved sysclk settings to late_probe.
4. Removed now empty snow_hw_params.
5. Removed snow_init
6. Used devm_snd_soc_register_card. Also removed empty remove function.
7. Removed non-DT handling as the driver is DT only.
Additional nits:
1. Renamed snow_driver_probe to snow_probe
2. Removed unused pm_ops.
3. Updated clock settings for I2S block (Earlier it was I2S_CDCLK,
whereas it should be I2S_RCLKSRC_0).
4. Removed 'card-name' DT property as it was not used in earlier
sound-card driver DT bindings. Will be added later.
Documentation/devicetree/bindings/sound/snow.txt | 17 +++
sound/soc/samsung/Kconfig| 10 ++
sound/soc/samsung/Makefile |2 +
sound/soc/samsung/snow.c | 122 ++
4 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/snow.txt
create mode 100644 sound/soc/samsung/snow.c
diff --git a/Documentation/devicetree/bindings/sound/snow.txt
b/Documentation/devicetree/bindings/sound/snow.txt
new file mode 100644
index 000..678b191
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/snow.txt
@@ -0,0 +1,17 @@
+Audio Binding for Snow boards
+
+Required properties:
+- compatible : Can be one of the following,
+ "google,snow-audio-max98090" or
+ "google,snow-audio-max98095"
+- samsung,i2s-controller: The phandle of the Samsung I2S controller
+- samsung,audio-codec: The phandle of the audio codec
+
+Example:
+
+sound {
+ compatible = "google,snow-audio-max98095";
+
+ samsung,i2s-controller = <>;
+ samsung,audio-codec = <>;
+};
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index f2e2891..50aa289 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -231,3 +231,13 @@ config SND_SOC_LITTLEMILL
select SND_SAMSUNG_I2S
select MFD_WM8994
select SND_SOC_WM8994
+
+config SND_SOC_SNOW
+ tristate "Audio support for Google Snow boards"
+ depends on SND_SOC_SAMSUNG
+ select SND_SOC_MAX98090
+ select SND_SOC_MAX98095
+ select SND_SAMSUNG_I2S
+ help
+ Say Y if you want to add audio support for various Snow
+ boards based on Exynos5 series of SoCs.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 86715d8..6d0212b 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -34,6 +34,7 @@ snd-soc-h1940-uda1380-objs := h1940_uda1380.o
snd-soc-rx1950-uda1380-objs := rx1950_uda1380.o
snd-soc-smdk-wm8580-objs := smdk_wm8580.o
snd-soc-smdk-wm8994-objs := smdk_wm8994.o
+snd-soc-snow-objs := snow.o
snd-soc-smdk-wm9713-objs := smdk_wm9713.o
snd-soc-s3c64xx-smartq-wm8987-objs := smartq_wm8987.o
snd-soc-goni-wm8994-objs := goni_wm8994.o
@@ -58,6 +59,7 @@ obj-$(CONFIG_SND_SOC_SAMSUNG_H1940_UDA1380) +=
snd-soc-h1940-uda1380.o
obj-$(CONFIG_SND_SOC_SAMSUNG_RX1950_UDA1380) += snd-soc-rx1950-uda1380.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8580) += snd-soc-smdk-wm8580.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994) += snd-soc-smdk-wm8994.o
+obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c
new file mode 100644
index 000..0fa89a4
--- /dev/null
+++ b/sound/soc/samsung/snow.c
@@ -0,0 +1,122 @@
+/*
+ * ASoC machine driver for Snow boards
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "i2s.h"
+
+#define FIN_PLL_RATE 2400
+
+static struct snd_soc_dai_link snow_dai[] = {
+ {
+ .name = "Primary",
+ .stream_name = "Primary",
+ .codec_dai_name =
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
This doesn't address any or the previous points: - common implementation instead of the godawful boilerplate code (and we even fixed most of this for Posix ACL by now, so even less reason to do the same crap again!) - common data structure with Posix ACLs And of course no real explanation why we need the braindead access/deny scheme at how it will get properly integrated with the system. So in this for a clear NAK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ARM: dts: am33xx: Add clock names for cpsw and cpts
Add CPSW fck and CPTS clock and clock names
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am33xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9770e35..d1e2b36 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -665,6 +665,8 @@
mac: ethernet@4a10 {
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
+ clocks = <_125mhz_gclk>, <_cpts_rft_clk>;
+ clock-names = "fck", "cpts";
cpdma_channels = <8>;
ale_entries = <1024>;
bd_ram_size = <0x2000>;
--
1.8.3.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 0/6] Add CPTS support for AM437x
The series adds CPTS support for AM4372. Patch 1 - CPTS clock name harcoding in the driver is removed. Easier to pass the clock name from dt rather than hardcoding in driver. Also in prepration for DRA7x CPTS support. Patch 2 - DT changes w.r.t clock changes for AM33xx. Patch 3 - Enable the CPTS support for both DRA7x and AM4372 in the driver. Patch 4 - Enable the Annexe F for L2 PTP for AM437x and DRA7x. Patch 5 - Change the default clocksource to dpll_core_m5 Patch 6 - DT changes for AM4372. George Cherian (6): drivers: net: cpts: Remove hardcoded clock name for CPTS ARM: dts: am33xx: Add clock names for cpsw and cpts drivers: net: cpsw: Enable CPTS for DRA7xx and AM4372 drivers: net: cpsw: Enable Annexe F Time sync ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk ARM: dts: am4372: Add clock names for cpsw and cpts arch/arm/boot/dts/am33xx.dtsi | 2 ++ arch/arm/boot/dts/am4372.dtsi | 2 ++ drivers/clk/ti/clk-43xx.c | 16 drivers/net/ethernet/ti/cpsw.c | 15 ++- drivers/net/ethernet/ti/cpts.c | 11 --- 5 files changed, 34 insertions(+), 12 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] drivers: net: cpsw: Enable Annexe F Time sync
Enable the Annex F Time Sync explicitly for DRA7x and AM4372.
With this enabled the L2 PTP is working.
while at that rename TS_BIT8 to TS_TTL_NONZERO
Signed-off-by: George Cherian
---
drivers/net/ethernet/ti/cpsw.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 085ffb5..af1423b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -248,7 +248,8 @@ struct cpsw_ss_regs {
#define TS_131 (1<<11) /* Time Sync Dest IP Addr 131 enable */
#define TS_130 (1<<10) /* Time Sync Dest IP Addr 130 enable */
#define TS_129 (1<<9) /* Time Sync Dest IP Addr 129 enable */
-#define TS_BIT8 (1<<8) /* ts_ttl_nonzero? */
+#define TS_TTL_NONZERO (1<<8) /* Time Sync Time To Live Non-zero enable
*/
+#define TS_ANNEX_F_EN (1<<6) /* Time Sync Annex F enable */
#define TS_ANNEX_D_EN (1<<4) /* Time Sync Annex D enable */
#define TS_LTYPE2_EN(1<<3) /* Time Sync LTYPE 2 enable */
#define TS_LTYPE1_EN(1<<2) /* Time Sync LTYPE 1 enable */
@@ -256,8 +257,9 @@ struct cpsw_ss_regs {
#define TS_RX_EN(1<<0) /* Time Sync Receive Enable */
#define CTRL_TS_BITS \
- (TS_320 | TS_319 | TS_132 | TS_131 | TS_130 | TS_129 | TS_BIT8 | \
-TS_ANNEX_D_EN | TS_LTYPE1_EN)
+ (TS_320 | TS_319 | TS_132 | TS_131 | TS_130 | TS_129 |\
+TS_TTL_NONZERO | TS_ANNEX_F_EN | TS_ANNEX_D_EN |\
+TS_LTYPE1_EN)
#define CTRL_ALL_TS_MASK (CTRL_TS_BITS | TS_TX_EN | TS_RX_EN)
#define CTRL_TX_TS_BITS (CTRL_TS_BITS | TS_TX_EN)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk
cpsw_cpts_rft_clk has got the choice of 3 clocksources
-dpll_core_m4_ck
-dpll_core_m5_ck
-dpll_disp_m2_ck
By default dpll_core_m4_ck is selected, witn this as clock
source the CPTS doesnot work properly. It gives clockcheck errors
while running PTP.
clockcheck: clock jumped backward or running slower than expected!
By selecting dpll_core_m5_ck as the clocksource fixes this issue.
In AM335x dpll_core_m5_ck is the default clocksource.
Signed-off-by: George Cherian
---
drivers/clk/ti/clk-43xx.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..b4877e0 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -110,9 +110,25 @@ static struct ti_dt_clk am43xx_clks[] = {
int __init am43xx_dt_clk_init(void)
{
+ struct clk *clk1, *clk2;
+
ti_dt_clocks_register(am43xx_clks);
omap2_clk_disable_autoidle_all();
+ /*
+* cpsw_cpts_rft_clk has got the choice of 3 clocksources
+* dpll_core_m4_ck, dpll_core_m5_ck and dpll_disp_m2_ck.
+* By default dpll_core_m4_ck is selected, witn this as clock
+* source the CPTS doesnot work properly. It gives clockcheck errors
+* while running PTP.
+* clockcheck: clock jumped backward or running slower than expected!
+* By selecting dpll_core_m5_ck as the clocksource fixes this issue.
+* In AM335x dpll_core_m5_ck is the default clocksource.
+*/
+ clk1 = clk_get_sys(NULL, "cpsw_cpts_rft_clk");
+ clk2 = clk_get_sys(NULL, "dpll_core_m5_ck");
+ clk_set_parent(clk1, clk2);
+
return 0;
}
--
1.8.3.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 6/6] ARM: dts: am4372: Add clock names for cpsw and cpts
Add CPSW fck and CPTS clock and clock names for AM4372 Signed-off-by: George Cherian --- arch/arm/boot/dts/am4372.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 36d523a..c2779f6 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -489,6 +489,8 @@ #address-cells = <1>; #size-cells = <1>; ti,hwmods = "cpgmac0"; + clocks = <_125mhz_gclk>, <_cpts_rft_clk>; + clock-names = "fck", "cpts"; status = "disabled"; cpdma_channels = <8>; ale_entries = <1024>; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] drivers: net: cpsw: Enable CPTS for DRA7xx and AM4372
Enable cpts hardware time stamping for Dra7xx and AM4372. This enables PTPv2 for DRA7xx and AM4372. Signed-off-by: George Cherian --- drivers/net/ethernet/ti/cpsw.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 36aa109..085ffb5 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -1398,7 +1398,8 @@ static int cpsw_hwtstamp_set(struct net_device *dev, struct ifreq *ifr) struct hwtstamp_config cfg; if (priv->version != CPSW_VERSION_1 && - priv->version != CPSW_VERSION_2) + priv->version != CPSW_VERSION_2 && + priv->version != CPSW_VERSION_3) return -EOPNOTSUPP; if (copy_from_user(, ifr->ifr_data, sizeof(cfg))) @@ -1443,6 +1444,7 @@ static int cpsw_hwtstamp_set(struct net_device *dev, struct ifreq *ifr) cpsw_hwtstamp_v1(priv); break; case CPSW_VERSION_2: + case CPSW_VERSION_3: cpsw_hwtstamp_v2(priv); break; default: @@ -1459,7 +1461,8 @@ static int cpsw_hwtstamp_get(struct net_device *dev, struct ifreq *ifr) struct hwtstamp_config cfg; if (priv->version != CPSW_VERSION_1 && - priv->version != CPSW_VERSION_2) + priv->version != CPSW_VERSION_2 && + priv->version != CPSW_VERSION_3) return -EOPNOTSUPP; cfg.flags = 0; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/5] ACPICA: OSL: Add direct inclusion of extra header.
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Monday, April 28, 2014 5:34 AM > > On Wednesday, April 23, 2014 02:53:52 PM Lv Zheng wrote: > > This is a linuxized result of an ACPICA commit to upgrade the extra > > header mechanism. > > > > This patch enhances the extra header solution to allow Linux to use > > ACPI_USE_NATIVE_INTERFACE_HEADER and the file name can be automatically > > replaced during ACPICA release process. Using this way, the rest of the > > ACPICA users needn't know the name of the extra header file. Lv Zheng. > > > > Signed-off-by: Lv Zheng > > --- > > include/acpi/acpi.h |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/include/acpi/acpi.h b/include/acpi/acpi.h > > index ca0cb60..682398b 100644 > > --- a/include/acpi/acpi.h > > +++ b/include/acpi/acpi.h > > @@ -62,8 +62,8 @@ > > #include /* Resource Descriptor structs */ > > #include /* OSL interfaces (ACPICA-to-OS) */ > > #include/* ACPI core subsystem external > > interfaces */ > > -#ifdef ACPI_NATIVE_INTERFACE_HEADER > > -#include ACPI_NATIVE_INTERFACE_HEADER > > +#ifdef ACPI_USE_NATIVE_INTERFACE_HEADER > > +#include > > #endif > > > > #endif /* __ACPI_H__ */ > > Well, I still think there's a better way. > > Introduce into ACPICA and put this into it: > > #if defined(_LINUX) || defined(__linux__) > #include > > #endif > > and then move stuff you want in acpi/acpi_opt.h into > acpi/platform/aclinuxex.h. > > Then, you'll have in acpi.h: > > #include /* Resource Descriptor structs */ > #include /* OSL interfaces (ACPICA-to-OS) */ > #include /* ACPI core subsystem external > interfaces */ > #include /* Extra environment-specific items */ > > > That should work I suppose, shouldn't it? I think this should work. I'll modify this patch according the above suggestion. Thanks and best regards -Lv > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.
[PATCH 1/6] drivers: net: cpts: Remove hardcoded clock name for CPTS
CPTS refclk name is hardcoded, which makes it fail in case of DRA7x
Remove the hardcoded clock name for CPTS refclk and get the same from DT.
Signed-off-by: George Cherian
---
drivers/net/ethernet/ti/cpts.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 2435139..0b6f6f7 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -236,13 +236,11 @@ static void cpts_overflow_check(struct work_struct *work)
schedule_delayed_work(>overflow_work, CPTS_OVERFLOW_PERIOD);
}
-#define CPTS_REF_CLOCK_NAME "cpsw_cpts_rft_clk"
-
-static void cpts_clk_init(struct cpts *cpts)
+static void cpts_clk_init(struct device *dev, struct cpts *cpts)
{
- cpts->refclk = clk_get(NULL, CPTS_REF_CLOCK_NAME);
+ cpts->refclk = devm_clk_get(dev, "cpts");
if (IS_ERR(cpts->refclk)) {
- pr_err("Failed to clk_get %s\n", CPTS_REF_CLOCK_NAME);
+ pr_err("Failed to get cpts refclk\n");
cpts->refclk = NULL;
return;
}
@@ -252,7 +250,6 @@ static void cpts_clk_init(struct cpts *cpts)
static void cpts_clk_release(struct cpts *cpts)
{
clk_disable(cpts->refclk);
- clk_put(cpts->refclk);
}
static int cpts_match(struct sk_buff *skb, unsigned int ptp_class,
@@ -390,7 +387,7 @@ int cpts_register(struct device *dev, struct cpts *cpts,
for (i = 0; i < CPTS_MAX_EVENTS; i++)
list_add(>pool_data[i].list, >pool);
- cpts_clk_init(cpts);
+ cpts_clk_init(dev, cpts);
cpts_write32(cpts, CPTS_EN, control);
cpts_write32(cpts, TS_PEND_EN, int_enable);
--
1.8.3.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: [RFC] A new CPU load metric for power-efficient scheduler: CPU ConCurrency
On Fri, Apr 25, 2014 at 03:53:34PM +0100, Morten Rasmussen wrote: > I fully agree. My point was that there is more to task consolidation > than just observing the degree of task parallelism. The system topology > has a lot to say when deciding whether or not to pack. That was the > motivation for proposing to have a power model for the system topology > to help making that decision. > > We do already have some per-task metric available that may be useful for > determining whether a workload is eligible for task packing. The > load_avg_contrib gives us an indication of the tasks cpu utilization and > we also count task wake-ups. If we tracked task wake-ups over time > (right now we only have the sum) we should be able to reason about the > number of wake-ups that a task causes. Lots of wake-ups and low > load_avg_contrib would indicate the task power is likely to be dominated > by the wake-up costs if it is placed on a cpu in a deep idle state. > > I fully agree that measuring the workloads while they are running is the > way to go. I'm just wondering if the proposed cpu concurrency measure > is sufficient to make the task packing decision for all system > topologies or if we need something that incorporates more system > topology information. If the latter, we may want to roll it all into > something like an energy_diff(src_cpu, dst_cpu, task) helper function > for use in load-balancing decisions. > Thank you. After CC, in the consolidation part, we do 1) attach the CPU topology to "help making that decision" and to be adaptive beyond our experimental platforms, and 2) intercept the current load balance for load and load balancing containment. Maybe, the way we consolidate workload differs from previous is: 1) we don't do it per task. We only see how many concurrent CPUs needed (on average and on prediction at power gated units) for the workload, and simply consolidate. 2) I am not sure it is sufficient either, :). But I can offer another two ways of how to interpret CC. 2.1) the current work-conserving load balance also uses CC, but instantaneous CC (similar to what PeterZ said to Vincent?). 2.2) CC vs. CPU utilization. CC is runqueue-length-weighted CPU utilization. If we change: "a = sum(concurrency * time) / period" to "a' = sum(1 * time) / period". Then a' is just about the CPU utilization. And the way we weight runqueue-length is the simplest one (excluding the exponential decays, and you may have other ways). The workloads they (not me) used to evaluate the "Workload Consolidation" is 1) 50+ perf/ux benchmarks (almost all of the magazine ones), and 2) ~10 power workloads, of course, they are the easiest ones, such as browsing, audio, video, recording, imaging, etc. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 5/5] ACPICA: Remove deprecated _LINUX definitions for ACPICA.
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Monday, April 28, 2014 5:39 AM
>
> On Wednesday, April 23, 2014 02:54:22 PM Lv Zheng wrote:
> > There are _LINUX defined so that when Linux kernel is compiled using broken
> > compilers that having not __linux__ defined can still include
> > from .
> >
> > This behavior is deprecated as all drivers/acpi/acpica files are compiled
> > without including , thus without _LINUX defined. As there is
> > no issues encountered when we compile ACPICA code without _LINUX defined,
> > it is OK to remove _LINUX from now.
> >
> > Signed-off-by: Lv Zheng
> > ---
> > include/linux/acpi.h |4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 7a8f2cd..9c559f7 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -31,10 +31,6 @@
> >
> > #ifdef CONFIG_ACPI
> >
> > -#ifndef _LINUX
> > -#define _LINUX
> > -#endif
> > -
> > #include
> > #include
>
> What about ? Should it still check if _LINUX is
> defined
> after this change?
If you mean these lines:
#if defined(_LINUX) || defined(__linux__)
#include
After deleting "_LINUX" from , acenv.h still can include
aclinux.h because of "__linux__".
Actually all drivers/acpi/acpica source files are compiled without including
, so "_LINUX" defined in this file is useless to Linux.
We needn't delete "_LINUX" from acenv.h.
"_LINUX" is only used in ACPICA makefiles, Linux never uses it:
https://github.com/acpica/acpica/blob/master/generate/unix/Makefile.config
ACPICA can be compiled using the following make command:
make HOST=_LINUX
I think this is the only usage of "_LINUX" for now.
Thanks and best regards
-Lv
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
NοΏ½rοΏ½οΏ½ybοΏ½XοΏ½οΏ½Η§vοΏ½^οΏ½)ήΊ{.nοΏ½+{zXοΏ½οΏ½οΏ½οΏ½ά¨}οΏ½οΏ½οΏ½Ζ zοΏ½:+vοΏ½οΏ½οΏ½zZ+οΏ½οΏ½+zfοΏ½οΏ½οΏ½hοΏ½οΏ½οΏ½~iοΏ½οΏ½οΏ½zοΏ½ οΏ½wοΏ½οΏ½οΏ½?οΏ½&οΏ½)ί’fοΏ½οΏ½^jΗ«yοΏ½mοΏ½οΏ½@AοΏ½aοΏ½οΏ½οΏ½
0οΏ½οΏ½hοΏ½οΏ½οΏ½i
[PATCH] sound: usb: Fix format string mismatch in mixer.c
Fix format string mismatch in parse_audio_selector_unit(). Signed-off-by: Masanari Iida --- sound/usb/mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index d40a285..6fe83e4 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1986,7 +1986,7 @@ static int parse_audio_selector_unit(struct mixer_build *state, int unitid, void if (! len && check_input_term(state, desc->baSourceID[i], ) >= 0) len = get_term_name(state, , namelist[i], MAX_ITEM_NAME_LEN, 0); if (! len) - sprintf(namelist[i], "Input %d", i); + sprintf(namelist[i], "Input %u", i); } kctl = snd_ctl_new1(_selectunit_ctl, cval); -- 2.0.0.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework
Hi,
On Fri, Apr 25, 2014 at 8:11 PM, Alan Stern wrote:
> On Fri, 25 Apr 2014, Vivek Gautam wrote:
>
>> From: Kamil Debski
>>
>> Add the phy provider, supplied by new Exynos-usb2phy using
>> Generic phy framework.
>> Keeping the support for older USB phy intact right now, in order
>> to prevent any functionality break in absence of relevant
>> device tree side change for ehci-exynos.
>> Once we move to new phy in the device nodes for ehci, we can
>> remove the support for older phys.
>>
>> Signed-off-by: Kamil Debski
>> [gautam.vi...@samsung.com: Addressed review comments from mailing list]
>> [gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
>> added support for new exynos5-usb2phy in generic phy framework]
>> [gautam.vi...@samsung.com: Edited the commit message]
>> Signed-off-by: Vivek Gautam
>
>> +static int exynos_ehci_phyg_off(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>
> Same comment as in the OHCI driver about ret.
Ok, will change this.
>
>> @@ -175,6 +269,7 @@ skip_phy:
>> fail_add_hcd:
>> if (exynos_ehci->phy)
>> usb_phy_shutdown(exynos_ehci->phy);
>> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
>> fail_io:
>> clk_disable_unprepare(exynos_ehci->clk);
>> fail_clk:
>> @@ -195,6 +290,8 @@ static int exynos_ehci_remove(struct platform_device
>> *pdev)
>> if (exynos_ehci->phy)
>> usb_phy_shutdown(exynos_ehci->phy);
>>
>> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
>> +
>
> In both these places, you need to test exynos_ehci->phyg before calling
> exynos_ehci_phyg_off().
>
> Maybe it would help to add exynos_ehci_phy_enable/disable routines,
> like in the OHCI driver.
Will move these statements as a part of enable()/disable() routines,
put necessary check there.
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Hi,
On Fri, Apr 25, 2014 at 8:06 PM, Alan Stern wrote:
> On Fri, 25 Apr 2014, Vivek Gautam wrote:
>
>> Add support to consume phy provided by Generic phy framework.
>> Keeping the support for older usb-phy intact right now, in order
>> to prevent any functionality break in absence of relevant
>> device tree side change for ohci-exynos.
>> Once we move to new phy in the device nodes for ohci, we can
>> remove the support for older phys.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Jingoo Han
>> Cc: Alan Stern
>
>
>> +static int exynos_ohci_phyg_on(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_on(phy[i]);
>> + if (ret)
>> + for (i--; i >= 0; i--)
>> + if (phy[i])
>> + phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>> +
>> +static int exynos_ohci_phyg_off(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>
> You probably shouldn't break out of this loop if ret is nonzero; you
> should continue to power off the remaining phys.
ok, will remove the 'ret' check in for loop.
>
> I'd be inclined to put these two routines directly into
> exynos_ohci_phy_enable() and exynos_ohci_phy_disable(), since they
> aren't used anywhere else.
Sure, will make these routines as a part of exynos_ohci_phy_enable()
and exynos_ohci_phy_disable().
>
>> @@ -151,6 +253,7 @@ skip_phy:
>>
>> fail_add_hcd:
>> exynos_ohci_phy_disable(pdev);
>> + exynos_ohci_phyg_off(exynos_ohci->phy_g);
>
> Why did you add this line? It doesn't do anything useful, because
> exynos_ohci_phy_disable() already calls exynos_ohci_phyg_off().
Ah ! my bad, will remove this.
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] linux/interrupt.h: fix new kernel-doc warnings
From: Randy Dunlap Fix new kernel-doc warnings in : Warning(include/linux/interrupt.h:219): No description found for parameter 'cpumask' Warning(include/linux/interrupt.h:219): Excess function parameter 'mask' description in 'irq_set_affinity' Warning(include/linux/interrupt.h:236): No description found for parameter 'cpumask' Warning(include/linux/interrupt.h:236): Excess function parameter 'mask' description in 'irq_force_affinity' Signed-off-by: Randy Dunlap --- include/linux/interrupt.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- lnx-315-rc3.orig/include/linux/interrupt.h +++ lnx-315-rc3/include/linux/interrupt.h @@ -210,7 +210,7 @@ extern int __irq_set_affinity(unsigned i /** * irq_set_affinity - Set the irq affinity of a given irq * @irq: Interrupt to set affinity - * @mask: cpumask + * @cpumask: cpumask * * Fails if cpumask does not contain an online CPU */ @@ -223,7 +223,7 @@ irq_set_affinity(unsigned int irq, const /** * irq_force_affinity - Force the irq affinity of a given irq * @irq: Interrupt to set affinity - * @mask: cpumask + * @cpumask: cpumask * * Same as irq_set_affinity, but without checking the mask against * online cpus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.15-rc3
Another week, another rc. So far, no big scares, and rc3 is
appropriately smaller than rc2 was, so we're following the right
trajectory here.
The statistics look fairly normal too, with half drivers (input, usb,
gpu, acpi, regulator..) and a third arch updates (much of it again arm
dts files, but other arm and some um updates too). The rest is misc,
but mainly concentrated in filesystem updates (btrfs and ext4).
Linus
---
Adam Thomson (1):
Input: da9055_onkey - remove use of regmap_irq_get_virq()
Alan Stern (1):
[SCSI] Fix command result state propagation
Alec Berg (1):
iio: querying buffer scan_mask should return 0/1
Alex Deucher (7):
drm/radeon: disable dpm on rv770 by default
drm/radeon/aux: fix hpd assignment for aux bus
drm/radeon: fix count in cik_sdma_ring_test()
drm/radeon: properly unregister hwmon interface (v2)
drm/radeon/pm: don't walk the crtc list before it has been
initialized (v2)
drm/radeon: fix ATPX detection on non-VGA GPUs
drm/radeon: don't allow runpm=1 on systems with out ATPX
Alex Elder (1):
ARM: spear: add __init to spear_clocksource_init()
Alexander Gordeev (3):
ahci: Ensure "MSI Revert to Single Message" mode is not enforced
ahci: Use pci_enable_msi_exact() instead of pci_enable_msi_range()
ahci: Do not receive interrupts sent by dummy ports
Alexander Shiyan (1):
ARM: 8024/1: Keep DEBUG_UART_{PHYS,VIRT} entries sorted
Alexander Stein (2):
spi: atmel: Fix scheduling while atomic bug
Input: ads7846 - fix device usage within attribute show
Alexandre Belloni (5):
iio: adc: at91_adc: Repair broken platform_data support
ARM: at91: at91sam9g45: change at91_adc name
ARM: at91: at91sam9260: change at91_adc name
iio: adc: at91_adc: correct default shtim value
iio: adc: mxs-lradc: fix warning when buidling on avr32
Andrea Adami (1):
ARM: pxa: hx4700.h: include "irqs.h" for PXA_NR_BUILTIN_GPIO
Andrew Lunn (2):
ARM: Kirkwood: Fix Atmel vendor prefix
ARM: Kirkwood: DT: Add missing vendor prefix
Andy Lutomirski (1):
x86, vdso: Make the vdso linker script compatible with Gold
Anton Ivanov (2):
um: Missing pipe handling
um: Memory corruption on startup
Arnd Bergmann (1):
phy: exynos: fix building as a module
Axel Lin (2):
regulator: pbias: Fix is_enabled callback implementation
regulator: pbias: Convert to use regmap helper functions
Azat Khuzhin (2):
ext4: initialize multi-block allocator before checking block descriptors
ext4: fix ext4_count_free_clusters() with EXT4FS_DEBUG and
bigalloc enabled
Bartlomiej Zolnierkiewicz (3):
pata_at91: fix ata_host_activate() failure handling
pata_arasan_cf: fix ata_host_activate() failure handling
pata_samsung_cf: fix ata_host_activate() failure handling
Beomho Seo (1):
iio: cm32181: Fix read integration time function
Bjorn Helgaas (1):
PNP: Work around BIOS defects in Intel MCH area reporting
BjΓΈrn Mork (6):
usb: qcserial: add Sierra Wireless EM7355
usb: qcserial: add Sierra Wireless MC73xx
usb: qcserial: add Sierra Wireless MC7305/MC7355
usb: option: add Olivetti Olicard 500
usb: option: add Alcatel L800MA
usb: option: add and update a number of CMOTech devices
Chanho Min (1):
arm64: init: Move of_clk_init to time_init
Chao Bi (1):
usb: gadget: ffs: race between ffs_epfile_io() and ffs_func_eps_disable()
Chen Gang (1):
ext4: fix 64-bit number truncation warning
Chris Mason (1):
Btrfs: limit the path size in send to PATH_MAX
Christian Borntraeger (1):
s390/ccwgroup: Fix memory corruption
Christian KΓΆnig (2):
drm/radeon: use fixed PPL ref divider if needed
drm/radeon: improve PLL limit handling in post div calculation
Christoph Hellwig (2):
[SCSI] don't reference freed command in scsi_init_sgtable
[SCSI] don't reference freed command in scsi_prep_return
Christoph Jaeger (2):
btrfs: fix use-after-free in mount_subvol()
intel_idle: fix IVT idle state table setting
Dan Carpenter (1):
clk: vexpress: NULL dereference on error path
Dan Williams (1):
libata/ahci: accommodate tag ordered controllers
Daniel Mack (2):
usb: musb: dsps: move debugfs_remove_recursive()
usb: phy: am335x-control: wait 1ms after power-up transitions
David Cohen (1):
usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
David Milburn (1):
ahci: do not request irq for dummy port
David Sterba (1):
btrfs: replace error code from btrfs_drop_extents
Denis Turischev (1):
xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
Dmitry Monakhov (2):
ext4: fix error handling in ext4_ext_shift_extents
ext4: always check ext4_ext_find_extent result
Domenico Andreoli (1):
ARM: Tidy up DTB Makefile entries
Doug Anderson (3):
serial:
[PATCH] block: Fix format string mismatch in cfq-iosched.c
Fix format string mismatch in cfq_var_show()
Signed-off-by: Masanari Iida
---
block/cfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 5063a0b..22dffeb 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -4460,7 +4460,7 @@ out_free:
static ssize_t
cfq_var_show(unsigned int var, char *page)
{
- return sprintf(page, "%d\n", var);
+ return sprintf(page, "%u\n", var);
}
static ssize_t
--
2.0.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] irqchip: vt8500: Switch to a simple write clear for Interrupt Status Register
According to the datasheet, the attribute of Interrupt Status Register is RW0S,
which means:
Software can read the register.
Software can also "write 1 to clear". "write 0" has no effect.
So the read/modify/write cycle is no necessary, switch to a simple write clear
instead.
Signed-off-by: Axel Lin
---
v2: Update commit log, this is a code simplification rather than bug fix.
drivers/irqchip/irq-vt8500.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-vt8500.c b/drivers/irqchip/irq-vt8500.c
index eb6e91e..a0085bc 100644
--- a/drivers/irqchip/irq-vt8500.c
+++ b/drivers/irqchip/irq-vt8500.c
@@ -87,14 +87,10 @@ static void vt8500_irq_mask(struct irq_data *d)
void __iomem *base = priv->base;
void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
u8 edge, dctr;
- u32 status;
edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
if (edge) {
- status = readl(stat_reg);
-
- status |= (1 << (d->hwirq & 0x1f));
- writel(status, stat_reg);
+ writel(BIT(d->hwirq & 0x1f), stat_reg);
} else {
dctr = readb(base + VT8500_ICDC + d->hwirq);
dctr &= ~VT8500_INT_ENABLE;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: vt8500: Switch to a simple write clear for Interrupt Status Register
2014-04-28 2:34 GMT+08:00 Thomas Gleixner : > On Sun, 27 Apr 2014, Axel Lin wrote: > >> According to the datasheet, the attribute of Interrupt Status Register is >> RW0S, >> which means: >> Software can read the register. >> Software can also "write 1 to clear". "write 0" has no effect. >> Thus switch the read/modify/write to a simple write clear. >> >> A read/modify/write does not make sense for an irq status register like this, >> since otherwise a read/modify/write can race with a device raising an >> interrupt >> and then clear the pending bit unintentionally. > > That's right, but what you are not seeing is that this is the mask > callback which is supposed to mask the interrupt at the interrupt > controller level. > > I have a hard time to see (even without reading the data sheet) how > clearing a potentially pending interrupt in the status register will > mask the interrupt line. ok, I'll send a v2 to update the commit log. Thanks for the review. Regards, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] cgroup, memcg: implement css->id and convert css_from_id() to use it
On 2014/4/25 5:02, Tejun Heo wrote: > Until now, cgroup->id has been used to identify all the associated > csses and css_from_id() takes cgroup ID and returns the matching css > by looking up the cgroup and then dereferencing the css associated > with it; however, now that the lifetimes of cgroup and css are > separate, this is incorrect and breaks on the unified hierarchy when a > controller is disabled and enabled back again before the previous > instance is released. > > This patch adds css->id which is a subsystem-unique ID and converts > css_from_id() to look up by the new css->id instead. memcg is the > only user of css_from_id() and also converted to use css->id instead. > netprio_cgroup also needs to be updated. > For traditional hierarchies, this shouldn't make any functional > difference. > > Signed-off-by: Tejun Heo > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Jianyu Zhan > --- > include/linux/cgroup.h | 9 > kernel/cgroup.c| 59 > -- > mm/memcontrol.c| 4 ++-- > 3 files changed, 49 insertions(+), 23 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Fix several sparc64 THP bugs.
From: mr...@linux.ee Date: Sat, 26 Apr 2014 23:14:59 +0300 (EEST) >> Meelis and Aaro, I've found and fixed several THP bugs for sparc64 >> over the last week or so. >> >> I cannot %100 account for the exit_mmap() WARN_ON that you two have >> been able to trigger, however I'd like you both to test the changes >> nonetheless. >> >> They are against 3.15 but they should apply cleanly all the way back >> to 3.13 >> >> Thanks in advance for testing. > > Tried it on Netra X1, Ultra 2 and V100 that were online (applied the > patches and enabled THP with defaulting to always). > > Ultra 2 did not boot up (will see on Monday). > > Netra X1 performed a simple dist-upgrade fine with this kernel. > > V100 boots up fine but as soon as I start aptitude, it just hangs with > nothing on console (tried it twice). Sigh, thanks for testing... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-BR] Re: [RFC] Only a.out QMAGIC format is working
Geyslan GregΓ³rio Bem writes: > > There should be chance to fix it. > > I think it too. If it's randomization the following could help: echo 0 > /proc/sys/kernel/randomize_va_space Does it? -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 3/5] ACPICA: Add to remove mis-ordered inclusion of from .
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Monday, April 28, 2014 5:37 AM
> To: Zheng, Lv
>
> On Wednesday, April 23, 2014 02:54:06 PM Lv Zheng wrote:
> > There is a mis-order inclusion for .
> >
> > As we will enforce including for all Linux ACPI users, we
> > can find the inclusion order is as follows:
> >
> >
> >
> >
> > (acenv.h before including aclinux.h)
> >
> > ...
> > (aclinux.h before including asm/acpi.h)
> > @Redundant@
> > (ACPICA specific stuff)
> > ...
> > ...
> > (Linux ACPI specific stuff) ? - - - - - - - - - - - - +
> > (aclinux.h after including asm/acpi.h) @Invisible@ |
> > (acenv.h after including aclinux.h) @Invisible@ |
> >other ACPICA headers @Invisible@ |
> > |..
> >|
> >|
> >(Excluded) |
> >(Linux ACPI specific stuff) ! <- - - - - - - - - - - - - +
> >
> > NOTE that, in ACPICA, is more like Kconfig
> > generated for Linux, it is meant to be included
> > before including any ACPICA code.
> >
> > In the above figure, there is a question mark for "Linux ACPI specific
> > stuff" in which should be included after including all other
> > ACPICA header files. Thus they really need to be moved to the position
> > marked with exclaimation mark or the definitions in the blocks marked with
> > "@Invisible@" will be invisible to such architecture specific "Linux ACPI
> > specific stuff" header blocks. This leaves 2 issues:
> > 1. All environmental definitions in these blocks should have a copy in the
> >area marked with "@Redundant@" if they are required by the "Linux ACPI
> >specific stuff".
> > 2. We cannot use any ACPICA defined types in .
> >
> > This patch splits architecture specific ACPICA stuff from to
> > fix this issue.
> >
> > Signed-off-by: Lv Zheng
> > Cc: Tony Luck
> > Cc: Fenghua Yu
> > Cc: linux-i...@vger.kernel.org
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Peter Anvin"
> > Cc: x...@kernel.org
> > ---
> > arch/ia64/include/asm/acenv.h | 71
> > +++
> > arch/ia64/include/asm/acpi.h| 50 ---
> > arch/x86/include/asm/acenv.h| 65 +++
> > arch/x86/include/asm/acpi.h | 45 -
> > include/acpi/platform/aclinux.h |2 +-
>
> Please rename the files first (in a separate patch) and then modify the
> renamed ones. That will make changes much easier to follow.
This patch doesn't provide a rename.
Currently, includes:
1. arch specific ACPI stuff
2. arch specific ACPICA stuff
This patch moves "2" to a separate file , thus no renaming happens
here.
Thanks and best regards
-Lv
>
> > 5 files changed, 137 insertions(+), 96 deletions(-)
> > create mode 100644 arch/ia64/include/asm/acenv.h
> > create mode 100644 arch/x86/include/asm/acenv.h
> >
> > diff --git a/arch/ia64/include/asm/acenv.h b/arch/ia64/include/asm/acenv.h
> > new file mode 100644
> > index 000..e0896eb
> > --- /dev/null
> > +++ b/arch/ia64/include/asm/acenv.h
> > @@ -0,0 +1,71 @@
> > +/*
> > + * IA64 specific ACPICA environments and implementation
> > + *
> > + * Copyright (C) 2014, Intel Corporation
> > + * Author: Lv Zheng
> > + *
> > + * 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_IA64_ACENV_H
> > +#define _ASM_IA64_ACENV_H
> > +
> > +#include
> > +
> > +#define COMPILER_DEPENDENT_INT64 long
> > +#define COMPILER_DEPENDENT_UINT64 unsigned long
> > +
> > +/*
> > + * Calling conventions:
> > + *
> > + * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
> > + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
> > + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
> > + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
> > + */
> > +#define ACPI_SYSTEM_XFACE
> > +#define ACPI_EXTERNAL_XFACE
> > +#define ACPI_INTERNAL_XFACE
> > +#define ACPI_INTERNAL_VAR_XFACE
> > +
> > +/* Asm macros */
> > +
> > +#define ACPI_FLUSH_CPU_CACHE()
> > +
> > +#ifdef CONFIG_ACPI
> > +
> > +static inline int
> > +ia64_acpi_acquire_global_lock(unsigned int *lock)
> > +{
> > + unsigned int old, new, val;
> > + do {
> > + old = *lock;
> > + new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
> > +
[PATCH] sched/deadline: remove dl_new checking condition from dl_task_timer()
From: "yjay.kim" yield_task_dl() sets dl.dl_new as 1 and dequeue current dl task. After that it expects that next bandwidth timer callback `dl_task_timer()` will replenish budget of dl task and enqueue it again. But current dl_task_timer() does nothing in case dl.dl_new is 1. So when dl task calls sched_yield(), it will never be scheduled again. dl_task_timer() should works in case dl_new is 1. Signed-off-by: yjay.kim --- kernel/sched/deadline.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 27ef409..6fb4004 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -522,7 +522,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer *timer) * different from SCHED_DEADLINE or changed its reservation * parameters (through sched_setscheduler()). */ - if (!dl_task(p) || dl_se->dl_new) + if (!dl_task(p)) goto unlock; sched_clock_tick(); -- 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/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/netlink/af_netlink.c between commit 5187cd055b6e ("netlink: Rename
netlink_capable netlink_allowed") from the net tree and commit
4f520900522f ("netlink: have netlink per-protocol bind function return an
error code") from the net-next 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 net/netlink/af_netlink.c
index 81dca96d2be6,92f4b6915e89..
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@@ -1492,8 -1445,8 +1510,8 @@@ static int netlink_bind(struct socket *
return -EINVAL;
/* Only superuser is allowed to listen multicasts */
- if (nladdr->nl_groups) {
+ if (groups) {
- if (!netlink_capable(sock, NL_CFG_F_NONROOT_RECV))
+ if (!netlink_allowed(sock, NL_CFG_F_NONROOT_RECV))
return -EPERM;
err = netlink_realloc_groups(sk);
if (err)
pgpTQOjua2zR4.pgp
Description: PGP signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/altera/altera_sgdma.c between commit 37c0ffaad214
("Altera TSE: Work around unaligned DMA receive packet issue with Altera
SGDMA") from the net tree and commit d42f157b3498 ("Altera TSE: Remove
unnecessary cast of void pointers") from the net-next tree.
I fixed it up (the former removes the code updated by the latter, so I
did that) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptr72LElx8R.pgp
Description: PGP signature
Re: [PATCH] acpi: try to trust cpu_index from x86_cpu_to_apicid
On 04/21/14 at 10:51pm, Rafael J. Wysocki wrote:
> On Tuesday, April 15, 2014 07:55:54 AM Baoquan He wrote:
> > In smp with multi cpus, when enter into kdump kernel with only 1 cpu,
> > a warning message is printed out:
> >
> > acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor
> >
> > In this case kdump kernel use the same ACPI tables as 1st kernel,
> > means lapic information is got from MADT. The acpi_id related to
> > this cpu index and lapic_id may not be 0, so the code to assign
> > value to cpu_index is not correct in this case per cpu0_initialized.
> > cpu index stored in x86_cpu_to_apicid need be respected.
> >
> > Now fix it in this patch per boot_cpu_physical_apicid. When cpu index
> > related to boot_cpu_physical_apicid is not stored in x86_cpu_to_apicid,
> > then we can say this is UP system running SMP kernel with no LAPIC in MADT
>
> Why don't you fix the warning message instead to cover this case too?
>
> > Signed-off-by: Baoquan He
> > ---
> > drivers/acpi/acpi_processor.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index c29c2c3..1ae460c 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -267,7 +267,7 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > pr->apic_id = apic_id;
> >
> > cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
> > - if (!cpu0_initialized) {
> > + if (!cpu0_initialized && (boot_cpu_physical_apicid == pr->apic_id)) {
Self NACK this patch.
Since this check should be limited on no LAPIC in MADT, so acpi_lapic is
better for this. Will repost after test.
Hi Rafael,
Do you have any suggestion on this fix?
Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Bugfix v2] sched: fix possible invalid memory access caused by CPU hot-addition
Intel platforms with Nehalem/Westmere/IvyBridge CPUs may support socket
hotplug/online at runtime. The CPU hot-addition flow is:
1) handle CPU hot-addition event
1.a) gather platform specific information
1.b) associate hot-added CPU with NUMA node
1.c) create CPU device
2) online hot-added CPU through sysfs:
2.a)cpu_up()
2.b)->try_online_node()
2.c)->hotadd_new_pgdat()
2.d)->node_set_online()
Between 1.b and 2.c, hot-added CPUs are associated with NUMA nodes
but those NUMA nodes may still be in offlined state. So we should
check node_online(nid) before calling kmalloc_node(nid) and friends,
otherwise it may cause invalid memory access as below.
[ 3663.324476] BUG: unable to handle kernel paging request at 1f08
[ 3663.332348] IP: [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.339719] PGD 82fe10067 PUD 82ebef067 PMD 0
[ 3663.344773] Oops: [#1] SMP
[ 3663.348455] Modules linked in: shpchp gpio_ich x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd microcode joydev sb_edac edac_core lpc_ich ipmi_si tpm_tis
ipmi_msghandler ioatdma wmi acpi_pad mac_hid lp parport ixgbe isci mpt2sas dca
ahci ptp libsas libahci raid_class pps_core scsi_transport_sas mdio hid_generic
usbhid hid
[ 3663.394393] CPU: 61 PID: 2416 Comm: cron Tainted: GW3.14.0-rc5+
#21
[ 3663.402643] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRIVTIN1.86B.0047.F03.1403031049 03/03/2014
[ 3663.414299] task: 88082fe54b00 ti: 880845fba000 task.ti:
880845fba000
[ 3663.422741] RIP: 0010:[] []
__alloc_pages_nodemask+0xb9/0x2d0
[ 3663.432857] RSP: 0018:880845fbbcd0 EFLAGS: 00010246
[ 3663.439265] RAX: 1f00 RBX: RCX:
[ 3663.447291] RDX: RSI: 0a8d RDI: 81a8d950
[ 3663.455318] RBP: 880845fbbd58 R08: 880823293400 R09: 0001
[ 3663.463345] R10: 0001 R11: R12: 002052d0
[ 3663.471363] R13: 880854c07600 R14: 0002 R15:
[ 3663.479389] FS: 7f2e8b99e800() GS:88105a40()
knlGS:
[ 3663.488514] CS: 0010 DS: ES: CR0: 80050033
[ 3663.495018] CR2: 1f08 CR3: 0008237b1000 CR4: 001407e0
[ 3663.503476] Stack:
[ 3663.505757] 811bd74d 880854c01d98 880854c01df0
880854c01dd0
[ 3663.514167] 0003208ca420 00075a5d84d0 88082fe54b00
811bb35f
[ 3663.522567] 880854c07600 0003 1f00
880845fbbd48
[ 3663.530976] Call Trace:
[ 3663.533753] [] ? deactivate_slab+0x41d/0x4f0
[ 3663.540421] [] ? new_slab+0x3f/0x2d0
[ 3663.546307] [] new_slab+0xa5/0x2d0
[ 3663.552001] [] __slab_alloc+0x35d/0x54a
[ 3663.558185] [] ? local_clock+0x25/0x30
[ 3663.564686] [] ? __do_page_fault+0x4ec/0x5e0
[ 3663.571356] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.578609] [] ? __raw_spin_lock_init+0x21/0x60
[ 3663.585570] [] kmem_cache_alloc_node_trace+0xa6/0x1d0
[ 3663.593112] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.600363] [] alloc_fair_sched_group+0xc4/0x190
[ 3663.607423] [] sched_create_group+0x3f/0x80
[ 3663.613994] [] sched_autogroup_create_attach+0x3f/0x1b0
[ 3663.621732] [] sys_setsid+0xea/0x110
[ 3663.628020] [] system_call_fastpath+0x1a/0x1f
[ 3663.634780] Code: 00 44 89 e7 e8 b9 f8 f4 ff 41 f6 c4 10 74 18 31 d2 be 8d
0a 00 00 48 c7 c7 50 d9 a8 81 e8 70 6a f2 ff e8 db dd 5f 00 48 8b 45 c8 <48> 83
78 08 00 0f 84 b5 01 00 00 48 83 c0 08 44 89 75 c0 4d 89
[ 3663.657032] RIP [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.664491] RSP
[ 3663.668429] CR2: 1f08
[ 3663.672659] ---[ end trace df13f08ed9de18ad ]---
Signed-off-by: Jiang Liu
---
Hi all,
We have improved log messages according to Peter's suggestion,
no code changes.
Thanks!
Gerry
---
kernel/sched/fair.c | 12 +++-
kernel/sched/rt.c | 11 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7570dd969c28..71be1b96662e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7487,7 +7487,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se;
- int i;
+ int i, nid;
tg->cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
if (!tg->cfs_rq)
@@ -7501,13 +7501,15 @@ int alloc_fair_sched_group(struct task_group *tg,
struct task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
for_each_possible_cpu(i) {
- cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
- GFP_KERNEL, cpu_to_node(i));
+ nid =
[PATCH 0/1] ftrace/ring_buffer: reset reader page after consuming read
Reading from the 'trace' file after force stopping (by signal) consuming read reveals there are stale trace entries in the output, this patch fixes the bug by resetting read/write pointers of reader page after the consuming read is stopped by force. The issue can be reproduced as below: echo 0 > tracing_on echo function > current_tracer echo 1 > tracing_on 1, read the trace file as normal cat trace | head -n 20 ... cat trace | head -n 20 The trace entries are changing at the head of the output. NOTE: If it's not changing at the start please repeat the reading several times because the tracer need time to fill up the whole buffer. 2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C cat trace_pipe Ctrl-C cat trace | head -n 200 ... cat trace | head -n 200 The trace entries at the head of the output stop changing, followed by changing trace entries. NOTE: Please carefully check the time stamps of the trace entries, the time stamps of some of them at the head stop changing in the consecutive read. The results of test 1 and 2 are not consistent with respect to the updating of trace buffers, some part of the trace buffers are not updated in the test 2 while all of them are updated in the test 1. And the result of test 1 is correct because the trace entries supposed to be changed for the reason the tracer works under overwrite mode by default. Thanks Shan Hai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ftrace/ring_buffer: reset reader page after consuming read was performed to the page
Reset the reader page to avoid reading old trace entries repeatedly
in non-consuming read after a force stopped(by signal) consuming read.
The force stopped reader might left the reader page half filled by the
writer while the commit and tail pages are on the page when it is stopped.
The reader page holds the old trace entries until next consuming reader
swaps the page into ring buffer because the reader page is not part of
ring buffer. The non-consuming reader gets the old data repeatedly because
the reading of ring buffer starts from reader page and the reader would not
swap the reader page into ring buffer for its non-consuming nature.
The issue can be reproduced as below:
echo 0 > tracing_on
echo function > current_tracer
echo 1 > tracing_on
1, read the trace file as normal
cat trace | head -n 20
...
cat trace | head -n 20
The trace entries are changing at the head of the output.
NOTE:
If it's not changing at the start please repeat the reading
several times because the tracer need time to fill up the
whole buffer.
2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C
cat trace_pipe
Ctrl-C
cat trace | head -n 200
...
cat trace | head -n 200
The trace entries at the head of the output stop changing,
followed by changing trace entries.
NOTE:
Please carefully check the time stamps of the trace entries,
the time stamps of some of them at the head stop changing
in the consecutive read.
The results of test 1 and 2 are not consistent with respect to the
updating of trace buffers, some part of the trace buffers are
not updated in the test 2 while all of them are updated in the
test 1.
And the result of test 1 is correct because the trace entries
supposed to be changed for the reason the tracer works under
overwrite mode by default.
Cc: sta...@vger.kernel.org
Signed-off-by: Shan Hai
---
kernel/trace/ring_buffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index c634868..76cf402 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3364,6 +3364,14 @@ static void rb_iter_reset(struct ring_buffer_iter *iter)
return;
iter->head = iter->head_page->read;
} else {
+ /* Reset the pointers because a force stopped(by signal)
+* consuming reader might left the page half filled.
+*/
+ local_set(_buffer->reader_page->write, 0);
+ local_set(_buffer->reader_page->entries, 0);
+ local_set(_buffer->reader_page->page->commit, 0);
+ cpu_buffer->reader_page->read = 0;
+
iter->head_page = cpu_buffer->reader_page;
iter->head = cpu_buffer->reader_page->read;
}
--
1.8.5.2.233.g932f7e4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: add OProfile support
On 2014/4/26 18:22, Ding Tianhong wrote: > On 2014/4/26 17:23, Catalin Marinas wrote: >> On 26 Apr 2014, at 09:38, Ding Tianhong wrote: >>> Add OProfile support for arm64, using the perf backend, and failing back >>> to generic timer based sampling if PMU interrupt is not supported. >>> >>> I have test this patch on Cortex-A53 and Cortex-A57 motherboard, the >>> OProfile >>> could work well by PMU irq or arch timer irq. >> >> This came up before a few times and we also had an implementation but >> decided not to merge it. We should rather get the user space oprofile to >> use the perf kernel API. >> >> Thatβs an old thread, it may have even made it into mainline oprofile >> but I havenβt followed the development: >> >> http://marc.info/?l=oprofile-list=133002515616302=2 >> >> Catalin >> Hi Cadtalin: Sorry I could not find the implementation that not to merge the orpfile support for aarch64 till now, and I still have questions that the existing code only support oprofile by arch timer event, but not PMU event, this patch only add HW PMU support for oprofile, it is more accurate and stable, can you give me more advise and appreciate for your help. Regards Ding > Ok, I will check it and then decide the next step, thanks for your feedback. > > Regards > Ding > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table
From: Dmitry Eremin
Local variable 'hash' is never used
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c
b/drivers/staging/lustre/lnet/lnet/api-ni.c
index 85b8d81..3f1fdaa 100644
--- a/drivers/staging/lustre/lnet/lnet/api-ni.c
+++ b/drivers/staging/lustre/lnet/lnet/api-ni.c
@@ -127,8 +127,7 @@ lnet_create_remote_nets_table(void)
static void
lnet_destroy_remote_nets_table(void)
{
- int i;
- struct list_head*hash;
+ int i;
if (the_lnet.ln_remote_nets_hash == NULL)
return;
@@ -137,7 +136,8 @@ lnet_destroy_remote_nets_table(void)
LASSERT(list_empty(_lnet.ln_remote_nets_hash[i]));
LIBCFS_FREE(the_lnet.ln_remote_nets_hash,
- LNET_REMOTE_NETS_HASH_SIZE * sizeof(*hash));
+ LNET_REMOTE_NETS_HASH_SIZE *
+ sizeof(the_lnet.ln_remote_nets_hash[0]));
the_lnet.ln_remote_nets_hash = NULL;
}
--
1.9.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 v3 3/4] staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected
From: Dmitry Eremin
Null pointer 'cp' that comes from line 2544 may be dereferenced
at line 2618.
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 6173e74..9bf6c94 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -2609,13 +2609,17 @@ kiblnd_rejected (kib_conn_t *conn, int reason, void
*priv, int priv_nob)
case IBLND_REJECT_MSG_QUEUE_SIZE:
CERROR("%s rejected: incompatible message queue
depth %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_queue_depth,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_queue_depth :
+ IBLND_MSG_QUEUE_SIZE(rej->ibr_version),
IBLND_MSG_QUEUE_SIZE(conn->ibc_version));
break;
case IBLND_REJECT_RDMA_FRAGS:
CERROR("%s rejected: incompatible # of RDMA
fragments %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_max_frags,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_max_frags :
+ IBLND_RDMA_FRAGS(rej->ibr_version),
IBLND_RDMA_FRAGS(conn->ibc_version));
break;
--
1.9.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 v3 0/4] Lustre Klocwork fixes
This is just splitting big lnet fixes patch from Klocwork static analysis tool into smaller bits. Reworked according to previous comments. Also, this time with correct CC list. Dmitry Eremin (2): staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected Oleg Drokin (2): staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips staging/lustre/lnet: fix potential null pointer dereference drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++-- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c| 4 drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++--- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 1.9.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 v3 4/4] staging/lustre/lnet: fix potential null pointer dereference
Pointer 'ni' checked for NULL at line 1569 may be passed to function and may be dereferenced there by passing argument 1 to function 'lnet_ni_notify_locked' at line 1621. found by Klocwork Insight tool Signed-off-by: Oleg Drokin CC: Dmitry Eremin CC: Liang Zhen --- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c index 995f509..926923a 100644 --- a/drivers/staging/lustre/lnet/lnet/router.c +++ b/drivers/staging/lustre/lnet/lnet/router.c @@ -145,7 +145,7 @@ lnet_ni_notify_locked(lnet_ni_t *ni, lnet_peer_t *lp) * NB individual events can be missed; the only guarantee is that you * always get the most recent news */ - if (lp->lp_notifying) + if (lp->lp_notifying || ni == NULL) return; lp->lp_notifying = 1; -- 1.9.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 v3 1/4] staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips
It should never be NULL because our interface list is up to date,
and even if it does, we'll just crash anyway so we are no better off.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 21d36ee..a391d13 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -793,8 +793,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
ip = peer->ksnp_passive_ips[i];
best_iface = ksocknal_ip2iface(peer->ksnp_ni, ip);
- /* peer passive ips are kept up to date */
- LASSERT(best_iface != NULL);
} else {
/* choose a new interface */
LASSERT (i == peer->ksnp_n_passive_ips);
@@ -835,8 +833,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
peer->ksnp_n_passive_ips = i+1;
}
- LASSERT (best_iface != NULL);
-
/* mark the best matching peer IP used */
j = ksocknal_match_peerip(best_iface, peerips, n_peerips);
peerips[j] = 0;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module: remove warning about waiting module removal.
Lucas De Marchi writes:
> Hi Rusty,
>
> On Thu, Apr 24, 2014 at 3:24 AM, Rusty Russell wrote:
>> We remove the waiting module removal in commit 3f2b9c9cdf38 (September
>> 2013), but it turns out that modprobe in kmod (< version 16) was
>> asking for waiting module removal. Noone noticed since modprobe would
>> check for 0 usage immediately before trying to remove the module, and
>> the race is unlikely.
>>
>> However, it means that anyone running old (but not ancient) kmod
>> versions is hitting the printk designed to see if anyone was running
>> "rmmod -w". All reports so far have been false positives, so remove
>> the warning.
>>
>> Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517
>> Reported-by: Valerio Vanni
>> Cc: Elliott, Robert (Server Storage)
>> Cc: sta...@kernel.org
>> Signed-off-by: Rusty Russell
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 11869408f79b..ae7821898bf2 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -815,9 +815,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
>> name_user,
>> return -EFAULT;
>> name[MODULE_NAME_LEN-1] = '\0';
>>
>> - if (!(flags & O_NONBLOCK))
>> - pr_warn("waiting module removal not supported: please
>> upgrade\n");
>> -
>> if (mutex_lock_interruptible(_mutex) != 0)
>> return -EINTR;
>>
>
> Ack.
>
> If you are going to apply this, do you think it'd be still good to
> patch kmod on distros, so at least modprobe -r uses O_NONBLOCK? Or
> having this patch in kernel is sufficient?
I think it's sufficient: distros will get this patch via stable. kmod
updates can occur at a natural pace.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ftrace/module: Hardcode ftrace_module_init() call into load_module()
Steven Rostedt writes: > [ > Rusty, you can take this patch, or if you want, you can give me > an Acked-by, and I'll push this through my tree. > ] Assuming you want this in the current kernel, I'll just ack: Acked-by: Rusty Russell Since I've got my "make RO/NX earlier" patch queued for *next* window, and yours need to go in before that... Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/lustre: Replace jobid acquiring with per node setting
Insted of meddling directly in process environment variables
(which is also not possible on certain platforms due to not exported
symbols), create jobid_name proc file to represent this info
(to be filled by job scheduler epilogue).
Signed-off-by: Oleg Drokin
CC: Andreas Dilger
---
.../staging/lustre/include/linux/libcfs/curproc.h | 1 -
.../staging/lustre/lustre/include/lprocfs_status.h | 1 +
drivers/staging/lustre/lustre/include/obd_class.h | 3 +
.../lustre/lustre/libcfs/linux/linux-curproc.c | 152 -
drivers/staging/lustre/lustre/obdclass/class_obd.c | 50 ++-
.../lustre/lustre/obdclass/linux/linux-module.c| 27
6 files changed, 44 insertions(+), 190 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/curproc.h
b/drivers/staging/lustre/include/linux/libcfs/curproc.h
index 8fd47c9..b314f34 100644
--- a/drivers/staging/lustre/include/linux/libcfs/curproc.h
+++ b/drivers/staging/lustre/include/linux/libcfs/curproc.h
@@ -56,7 +56,6 @@
/* check if task is running in compat mode.*/
#define current_pid() (current->pid)
#define current_comm() (current->comm)
-int cfs_get_environ(const char *key, char *value, int *val_len);
typedef __u32 cfs_cap_t;
diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index 9ce12c7..1b7f6a9 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -369,6 +369,7 @@ static inline void s2dhms(struct dhms *ts, time_t secs)
#define JOBSTATS_JOBID_VAR_MAX_LEN 20
#define JOBSTATS_DISABLE "disable"
#define JOBSTATS_PROCNAME_UID "procname_uid"
+#define JOBSTATS_NODELOCAL "nodelocal"
extern int lprocfs_write_frac_helper(const char *buffer, unsigned long count,
int *val, int mult);
diff --git a/drivers/staging/lustre/lustre/include/obd_class.h
b/drivers/staging/lustre/lustre/include/obd_class.h
index 61ba370..e265820 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -2182,6 +2182,9 @@ void class_exit_uuidlist(void);
int mea_name2idx(struct lmv_stripe_md *mea, const char *name, int namelen);
int raw_name2idx(int hashtype, int count, const char *name, int namelen);
+/* class_obd.c */
+extern char obd_jobid_node[];
+
/* prng.c */
#define ll_generate_random_uuid(uuid_out) cfs_get_random_bytes(uuid_out,
sizeof(class_uuid_t))
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
index e74c3e2..bd301ce 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
@@ -100,158 +100,6 @@ cfs_cap_t cfs_curproc_cap_pack(void)
return cap;
}
-static int cfs_access_process_vm(struct task_struct *tsk, unsigned long addr,
-void *buf, int len, int write)
-{
- /* Just copied from kernel for the kernels which doesn't
-* have access_process_vm() exported */
- struct mm_struct *mm;
- struct vm_area_struct *vma;
- struct page *page;
- void *old_buf = buf;
-
- mm = get_task_mm(tsk);
- if (!mm)
- return 0;
-
- down_read(>mmap_sem);
- /* ignore errors, just check how much was successfully transferred */
- while (len) {
- int bytes, rc, offset;
- void *maddr;
-
- rc = get_user_pages(tsk, mm, addr, 1,
-write, 1, , );
- if (rc <= 0)
- break;
-
- bytes = len;
- offset = addr & (PAGE_SIZE-1);
- if (bytes > PAGE_SIZE-offset)
- bytes = PAGE_SIZE-offset;
-
- maddr = kmap(page);
- if (write) {
- copy_to_user_page(vma, page, addr,
- maddr + offset, buf, bytes);
- set_page_dirty_lock(page);
- } else {
- copy_from_user_page(vma, page, addr,
- buf, maddr + offset, bytes);
- }
- kunmap(page);
- page_cache_release(page);
- len -= bytes;
- buf += bytes;
- addr += bytes;
- }
- up_read(>mmap_sem);
- mmput(mm);
-
- return buf - old_buf;
-}
-
-/* Read the environment variable of current process specified by @key. */
-int cfs_get_environ(const char *key, char *value, int *val_len)
-{
- struct mm_struct *mm;
- char *buffer, *tmp_buf = NULL;
- int buf_len = PAGE_CACHE_SIZE;
- int key_len = strlen(key);
- unsigned long addr;
- int rc;
-
- buffer =
[PATCH 3.2 08/94] vhost: fix total length when packets are too short
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
[ Upstream commit d8316f3991d207fe32881a9ac20241be8fa2bad0 ]
When mergeable buffers are disabled, and the
incoming packet is too large for the rx buffer,
get_rx_bufs returns success.
This was intentional in order for make recvmsg
truncate the packet and then handle_rx would
detect err != sock_len and drop it.
Unfortunately we pass the original sock_len to
recvmsg - which means we use parts of iov not fully
validated.
Fix this up by detecting this overrun and doing packet drop
immediately.
CVE-2014-0077
Signed-off-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/vhost/net.c | 14 ++
1 file changed, 14 insertions(+)
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -346,6 +346,12 @@ static int get_rx_bufs(struct vhost_virt
*iovcount = seg;
if (unlikely(log))
*log_num = nlogs;
+
+ /* Detect overrun */
+ if (unlikely(datalen > 0)) {
+ r = UIO_MAXIOV + 1;
+ goto err;
+ }
return headcount;
err:
vhost_discard_vq_desc(vq, headcount);
@@ -400,6 +406,14 @@ static void handle_rx(struct vhost_net *
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
break;
+ /* On overrun, truncate and discard */
+ if (unlikely(headcount > UIO_MAXIOV)) {
+ msg.msg_iovlen = 1;
+ err = sock->ops->recvmsg(NULL, sock, ,
+1, MSG_DONTWAIT | MSG_TRUNC);
+ pr_debug("Discarded rx packet: len %zd\n", sock_len);
+ continue;
+ }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 86/94] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: "H. Peter Anvin"
commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.
The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer. We have
a software workaround for that ("espfix") for the 32-bit kernel, but
it relies on a nonzero stack segment base which is not available in
32-bit mode.
Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
(no V86 mode), and most (if not quite all) 64-bit processors support
virtualization for the users who really need it, simply reject
attempts at creating a 16-bit segment when running on top of a 64-bit
kernel.
Cc: Linus Torvalds
Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9...@git.kernel.org
Signed-off-by: Ben Hutchings
---
arch/x86/kernel/ldt.c | 11 +++
1 file changed, 11 insertions(+)
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -230,6 +230,17 @@ static int write_ldt(void __user *ptr, u
}
}
+ /*
+* On x86-64 we do not support 16-bit segments due to
+* IRET leaking the high bits of the kernel stack address.
+*/
+#ifdef CONFIG_X86_64
+ if (!ldt_info.seg_32bit) {
+ error = -EINVAL;
+ goto out_unlock;
+ }
+#endif
+
fill_ldt(, _info);
if (oldmode)
ldt.avl = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware
On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot wrote:
> nvc0_graph_ctor() would only let the graphics engine be enabled if its
> oclass has a proper microcode linked to it. This prevents GR from being
> enabled at all on chips that rely exclusively on external firmware, even
> though such a use-case is valid.
>
> Relax the conditions enabling the GR engine to also include the case
> where an external firmware has also been loaded.
I'm happy to take this patch as-is. I do wonder if we should do
something like this though:
if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", oclass->fecs.ucode == NULL))
Which will automatically switch to external firmware if there's no
internal implementation available.
Thoughts? This could be a separate patch even, if preferred.
Thanks,
Ben.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> index f3c7329da0a0..e5b75f189988 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> @@ -1259,10 +1259,13 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
> nouveau_object *engine,
> struct nvc0_graph_oclass *oclass = (void *)bclass;
> struct nouveau_device *device = nv_device(parent);
> struct nvc0_graph_priv *priv;
> + bool use_ext_fw, enable;
> int ret, i;
>
> - ret = nouveau_graph_create(parent, engine, bclass,
> - (oclass->fecs.ucode != NULL), );
> + use_ext_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
> + enable = use_ext_fw || oclass->fecs.ucode != NULL;
> +
> + ret = nouveau_graph_create(parent, engine, bclass, enable, );
> *pobject = nv_object(priv);
> if (ret)
> return ret;
> @@ -1272,7 +1275,7 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
> nouveau_object *engine,
>
> priv->base.units = nvc0_graph_units;
>
> - if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", false)) {
> + if (use_ext_fw) {
> nv_info(priv, "using external firmware\n");
> if (nvc0_graph_ctor_fw(priv, "fuc409c", >fuc409c) ||
> nvc0_graph_ctor_fw(priv, "fuc409d", >fuc409d) ||
> --
> 1.9.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 06/94] ipv6: Avoid unnecessary temporary addresses being generated
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Heiner Kallweit
[ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]
tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.
Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/addrconf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -900,8 +900,11 @@ retry:
* Lifetime is greater than REGEN_ADVANCE time units. In particular,
* an implementation must not create a temporary address with a zero
* Preferred Lifetime.
+* Use age calculation as in addrconf_verify to avoid unnecessary
+* temporary addresses being generated.
*/
- if (tmp_prefered_lft <= regen_advance) {
+ age = (now - tmp_tstamp + ADDRCONF_TIMER_FUZZ_MINUS) / HZ;
+ if (tmp_prefered_lft <= regen_advance + age) {
in6_ifa_put(ifp);
in6_dev_put(idev);
ret = -1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 87/94] target/tcm_fc: Fix use-after-free of ft_tpg
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Grover
commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream.
ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
tport when the tpg is being removed. Set this pointer in ft_tport_create,
or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
a deleted object.
This patch sets tpg->tport in ft_tport_create, because that's what
ft_del_tpg checks, and is the only way to get back to the tport to
clear tport->tpg.
The bug was occuring when:
- lport created, tport (our per-lport, per-provider context) is
allocated.
tport->tpg = NULL
- tpg created
- a PRLI is received. ft_tport_create is called, tpg is found and
tport->tpg is set
- tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
set, tport->tpg is not cleared and points at freed memory
- Future calls to ft_tport_create return tport via first conditional,
instead of searching for new tpg by calling ft_lport_find_tpg.
tport->tpg is still invalid, and will access freed memory.
see https://bugzilla.redhat.com/show_bug.cgi?id=1071340
Signed-off-by: Andy Grover
Signed-off-by: Nicholas Bellinger
Signed-off-by: Ben Hutchings
---
drivers/target/tcm_fc/tfc_sess.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/target/tcm_fc/tfc_sess.c
+++ b/drivers/target/tcm_fc/tfc_sess.c
@@ -72,6 +72,7 @@ static struct ft_tport *ft_tport_create(
if (tport) {
tport->tpg = tpg;
+ tpg->tport = tport;
return tport;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 75/94] sh: fix format string bug in stack tracer
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Matt Fleming
commit a0c32761e73ccbf592b702f284221fea8040 upstream.
Kees reported the following error:
arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no
format arguments [-Werror=format-security]
Use the "%s" format so that it's impossible to interpret 'data' as a
format string.
Signed-off-by: Matt Fleming
Reported-by: Kees Cook
Acked-by: Kees Cook
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
arch/sh/kernel/dumpstack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -80,7 +80,7 @@ static int print_trace_stack(void *data,
*/
static void print_trace_address(void *data, unsigned long addr, int reliable)
{
- printk(data);
+ printk("%s", (char *)data);
printk_address(addr, reliable);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 25/94] ARM: 7954/1: mm: remove remaining domain support from ARMv6
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
commit b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream.
CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is
because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do
not have hardware thread registers. The lack of these registers requires
the kernel to update the vectors page at each context switch in order to
write a new TLS pointer. This write must be done via the userspace
mapping, since aliasing caches can lead to expensive flushing when using
kmap. Finally, this requires the vectors page to be mapped r/w for
kernel and r/o for user, which has implications for things like put_user
which must trigger CoW appropriately when targetting user pages.
The upshot of all this is that a v6/v7 kernel makes use of domains to
segregate kernel and user memory accesses. This has the nasty
side-effect of making device mappings executable, which has been
observed to cause subtle bugs on recent cores (e.g. Cortex-A15
performing a speculative instruction fetch from the GIC and acking an
interrupt in the process).
This patch solves this problem by removing the remaining domain support
from ARMv6. A new memory type is added specifically for the vectors page
which allows that page (and only that page) to be mapped as user r/o,
kernel r/w. All other user r/o pages are mapped also as kernel r/o.
Patch co-developed with Russell King.
Signed-off-by: Will Deacon
Signed-off-by: Russell King
[bwh: Backported to 3.2:
- Adjust filename, context
- Drop condition on CONFIG_ARM_LPAE]
Signed-off-by: Ben Hutchings
---
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -3,11 +3,6 @@
#ifdef __KERNEL__
-#if defined(CONFIG_CPU_USE_DOMAINS) && defined(CONFIG_SMP)
-/* ARM doesn't provide unprivileged exclusive memory accessors */
-#include
-#else
-
#include
#include
#include
@@ -163,6 +158,5 @@ futex_atomic_op_inuser (int encoded_op,
return ret;
}
-#endif /* !(CPU_USE_DOMAINS && SMP) */
#endif /* __KERNEL__ */
#endif /* _ASM_ARM_FUTEX_H */
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -139,6 +139,7 @@
#define L_PTE_MT_DEV_NONSHARED (_AT(pteval_t, 0x0c) << 2) /* 1100 */
#define L_PTE_MT_DEV_WC(_AT(pteval_t, 0x09) << 2) /* 1001
*/
#define L_PTE_MT_DEV_CACHED(_AT(pteval_t, 0x0b) << 2) /* 1011 */
+#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x0f) << 2) /* */
#define L_PTE_MT_MASK (_AT(pteval_t, 0x0f) << 2)
#endif /* _ASM_PGTABLE_2LEVEL_H */
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -458,7 +458,6 @@ config CPU_32v5
config CPU_32v6
bool
select TLS_REG_EMUL if !CPU_32v6K && !MMU
- select CPU_USE_DOMAINS if CPU_V6 && MMU
config CPU_32v6K
bool
@@ -652,7 +651,7 @@ config ARM_THUMBEE
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
- depends on !CPU_USE_DOMAINS && CPU_V7
+ depends on CPU_V7
select HAVE_PROC_CPU if PROC_FS
default y if SMP
help
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -426,6 +426,14 @@ static void __init build_mem_type_table(
mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
}
/*
+* We don't use domains on ARMv6 (since this causes problems with
+* v6/v7 kernels), so we must use a separate memory type for user
+* r/o, kernel r/w to map the vectors page.
+*/
+ if (cpu_arch == CPU_ARCH_ARMv6)
+ vecs_pgprot |= L_PTE_MT_VECTORS;
+
+ /*
* ARMv6 and above have extended page tables.
*/
if (cpu_arch >= CPU_ARCH_ARMv6 && (cr & CR_XP)) {
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -106,13 +106,9 @@
* 100x 1 0 1 r/o no acc
* 10x0 1 0 1 r/o no acc
* 1011 0 0 1 r/w no acc
- * 110x 0 1 0 r/w r/o
- * 11x0 0 1 0 r/w r/o
- * 0 1 1 r/w r/w
- *
- * If !CONFIG_CPU_USE_DOMAINS, the following permissions are changed:
* 110x 1 1 1 r/o r/o
* 11x0 1 1 1 r/o r/o
+ * 0 1 1 r/w r/w
*/
.macro armv6_mt_table pfx
\pfx\()_mt_table:
@@ -131,7 +127,7 @@
.long PTE_EXT_TEX(2) @
L_PTE_MT_DEV_NONSHARED
.long 0x00@ unused
.long 0x00@ unused
- .long 0x00@ unused
+ .long PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@
L_PTE_MT_VECTORS
.endm
.macro armv6_set_pte_ext pfx
@@ -152,24 +148,21 @@
tst r1, #L_PTE_USER
orrne r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
- @ allow kernel read/write access to read-only
Re: [PATCH V5 12/12] ACPI: introduce .handle_children flag for acpi scan handler
On Mon, 2014-04-28 at 00:26 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 08, 2014 12:06:59 AM Zhang Rui wrote:
> > For some devices with scan handler attached, their children devices
> > are enumerated by the scan handler, indirectly.
>
> This isn't the case really. They are enumerated by bus controller drivers
> for the buses they are on.
>
that's what I mean by saying "indirectly". :)
> > In this case, we do not want to enumerate the children devices in
> > acpi scan code explicitly.
> >
> > Thus a new flag .handle_children is introduced in this patch.
> >
> > For scan handlers with this flag set, we will do default enumeration neither
> > for the attached devices nor for the children of the attached devices.
>
> I'm not sure if that is the right approach. I would prefer that to be
> handled in a more fine-graind manner, like a flag per device ID or something
> similar?
>
hmmm, how about this,
first, keep the device->flags.no_child_enumeration flag introduced in
this patch
second, set the flag explicitly, for specified devices, in the scan
handler .attach() function.
thanks,
rui
> > Signed-off-by: Zhang Rui
> > ---
> > drivers/acpi/acpi_lpss.c |2 ++
> > drivers/acpi/scan.c | 28 ++--
> > include/acpi/acpi_bus.h |4 +++-
> > 3 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> > index 965428f..da0a3d4 100644
> > --- a/drivers/acpi/acpi_lpss.c
> > +++ b/drivers/acpi/acpi_lpss.c
> > @@ -521,6 +521,7 @@ static struct acpi_scan_handler lpss_handler = {
> > .attach = acpi_lpss_create_device,
> > .bind = acpi_lpss_bind,
> > .unbind = acpi_lpss_unbind,
> > + .handle_children = true,
> > };
> >
> > #endif /* CONFIG_X86_INTEL_LPSS */
> > @@ -534,6 +535,7 @@ static int acpi_lpss_dummy_attach(struct acpi_device
> > *adev,
> > static struct acpi_scan_handler lpss_dummy_handler = {
> > .ids = acpi_lpss_device_ids,
> > .attach = acpi_lpss_dummy_attach,
> > + .handle_children = true,
> > };
> >
> > void __init acpi_lpss_init(void)
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 44c4668..4ea867e 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -2073,6 +2073,31 @@ static acpi_status acpi_bus_check_add(acpi_handle
> > handle, u32 lvl_not_used,
> > return AE_OK;
> > }
> >
> > +static void acpi_do_default_enumeration(struct acpi_device *device)
> > +{
> > + /*
> > +* Do not do enumeration for device object that
> > +* its parent doesn't want to
> > +*/
> > + if (device->parent && device->parent->flags.no_child_enumeration) {
> > + device->flags.no_child_enumeration = 1;
> > + return;
> > + }
> > +
> > + /* Do not do enumeration for device object with scan handler attached */
> > + if (device->handler) {
> > + if (device->handler->handle_children)
> > + device->flags.no_child_enumeration = 1;
> > + return;
> > + }
> > +
> > + /* Do not do enumeration for device object w/o platform_id */
> > + if (!device->pnp.type.platform_id)
> > + return;
> > +
> > + acpi_create_platform_device(device, NULL);
> > +}
> > +
> > static int acpi_scan_attach_handler(struct acpi_device *device)
> > {
> > struct acpi_hardware_id *hwid;
> > @@ -2095,8 +2120,7 @@ static int acpi_scan_attach_handler(struct
> > acpi_device *device)
> > }
> > }
> >
> > - if (device->pnp.type.platform_id && !device->handler)
> > - acpi_create_platform_device(device, NULL);
> > + acpi_do_default_enumeration(device);
> >
> > return ret;
> > }
> > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> > index ec92ad3..4724fe5 100644
> > --- a/include/acpi/acpi_bus.h
> > +++ b/include/acpi/acpi_bus.h
> > @@ -137,6 +137,7 @@ struct acpi_scan_handler {
> > void (*bind)(struct device *phys_dev);
> > void (*unbind)(struct device *phys_dev);
> > struct acpi_hotplug_profile hotplug;
> > + bool handle_children;
> > };
> >
> > /*
> > @@ -207,7 +208,8 @@ struct acpi_device_flags {
> > u32 no_hotplug:1;
> > u32 hotplug_notify:1;
> > u32 is_dock_station:1;
> > - u32 reserved:22;
> > + u32 no_child_enumeration:1;
> > + u32 reserved:21;
> > };
> >
> > /* File System */
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 17/94] Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Dave Kleikamp [ Upstream commit 16932237f2978a2265662f8de4af743b1f55a209 ] This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2. This commit broke the behavior of __copy_from_user_inatomic when it is only partially successful. Instead of returning the number of bytes not copied, it now returns 1. This translates to the wrong value being returned by iov_iter_copy_from_user_atomic. xfstests generic/246 and LTP writev01 both fail on btrfs and nfs because of this. Signed-off-by: Dave Kleikamp Cc: Hugh Dickins Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- arch/sparc/include/asm/uaccess_64.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/include/asm/uaccess_64.h b/arch/sparc/include/asm/uaccess_64.h index 3e1449f..6d6c731 100644 --- a/arch/sparc/include/asm/uaccess_64.h +++ b/arch/sparc/include/asm/uaccess_64.h @@ -267,8 +267,8 @@ extern long __strnlen_user(const char __user *, long len); #define strlen_user __strlen_user #define strnlen_user __strnlen_user -#define __copy_to_user_inatomic ___copy_to_user -#define __copy_from_user_inatomic ___copy_from_user +#define __copy_to_user_inatomic __copy_to_user +#define __copy_from_user_inatomic __copy_from_user #endif /* __ASSEMBLY__ */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 33/94] [media] media: gspca: sn9c20x: add ID for Genius Look 1320 V2
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Wolfram Sang
commit 61f0319193c44adbbada920162d880b1fdb3aeb3 upstream.
Signed-off-by: Wolfram Sang
Signed-off-by: Hans de Goede
Signed-off-by: Mauro Carvalho Chehab
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings
---
Documentation/video4linux/gspca.txt | 1 +
drivers/media/video/gspca/sn9c20x.c | 1 +
2 files changed, 2 insertions(+)
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -55,6 +55,7 @@ zc3xx 0458:700f Genius VideoCam Web V2
sonixj 0458:7025 Genius Eye 311Q
sn9c20x0458:7029 Genius Look 320s
sonixj 0458:702e Genius Slim 310 NB
+sn9c20x0458:7045 Genius Look 1320 V2
sn9c20x0458:704a Genius Slim 1320
sn9c20x0458:704c Genius i-Look 1321
sn9c20x045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -2521,6 +2521,7 @@ static const struct usb_device_id device
{USB_DEVICE(0x045e, 0x00f4), SN9C20X(OV9650, 0x30, 0)},
{USB_DEVICE(0x145f, 0x013d), SN9C20X(OV7660, 0x21, 0)},
{USB_DEVICE(0x0458, 0x7029), SN9C20X(HV7131R, 0x11, 0)},
+ {USB_DEVICE(0x0458, 0x7045), SN9C20X(MT9M112, 0x5d, LED_REVERSE)},
{USB_DEVICE(0x0458, 0x704a), SN9C20X(MT9M112, 0x5d, 0)},
{USB_DEVICE(0x0458, 0x704c), SN9C20X(MT9M112, 0x5d, 0)},
{USB_DEVICE(0xa168, 0x0610), SN9C20X(HV7131R, 0x11, 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 3.2 14/94] isdnloop: several buffer overflows
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ]
There are three buffer overflows addressed in this patch.
1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
then copy it into a 60 character buffer. I have made the destination
buffer 64 characters and I'm changed the sprintf() to a snprintf().
2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
character buffer so we have 54 characters. The ->eazlist[] is 11
characters long. I have modified the code to return if the source
buffer is too long.
3) In isdnloop_command() the cbuf[] array was 60 characters long but the
max length of the string then can be up to 79 characters. I made the
cbuf array 80 characters long and changed the sprintf() to snprintf().
I also removed the temporary "dial" buffer and changed it to use "p"
directly.
Unfortunately, we pass the "cbuf" string from isdnloop_command() to
isdnloop_writecmd() which truncates anything over 60 characters to make
it fit in card->omsg[]. (It can accept values up to 255 characters so
long as there is a '\n' character every 60 characters). For now I have
just fixed the memory corruption bug and left the other problems in this
driver alone.
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/isdn/isdnloop/isdnloop.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -518,9 +518,9 @@ static isdnloop_stat isdnloop_cmd_table[
static void
isdnloop_fake_err(isdnloop_card * card)
{
- char buf[60];
+ char buf[64];
- sprintf(buf, "E%s", card->omsg);
+ snprintf(buf, sizeof(buf), "E%s", card->omsg);
isdnloop_fake(card, buf, -1);
isdnloop_fake(card, "NAK", -1);
}
@@ -903,6 +903,8 @@ isdnloop_parse_cmd(isdnloop_card * card)
case 7:
/* 0x;EAZ */
p += 3;
+ if (strlen(p) >= sizeof(card->eazlist[0]))
+ break;
strcpy(card->eazlist[ch - 1], p);
break;
case 8:
@@ -1133,7 +1135,7 @@ isdnloop_command(isdn_ctrl * c, isdnloop
{
ulong a;
int i;
- char cbuf[60];
+ char cbuf[80];
isdn_ctrl cmd;
isdnloop_cdef cdef;
@@ -1198,7 +1200,6 @@ isdnloop_command(isdn_ctrl * c, isdnloop
break;
if ((c->arg & 255) < ISDNLOOP_BCH) {
char *p;
- char dial[50];
char dcode[4];
a = c->arg;
@@ -1210,10 +1211,10 @@ isdnloop_command(isdn_ctrl * c, isdnloop
} else
/* Normal Dial */
strcpy(dcode, "CAL");
- strcpy(dial, p);
- sprintf(cbuf, "%02d;D%s_R%s,%02d,%02d,%s\n",
(int) (a + 1),
- dcode, dial, c->parm.setup.si1,
- c->parm.setup.si2, c->parm.setup.eazmsn);
+ snprintf(cbuf, sizeof(cbuf),
+"%02d;D%s_R%s,%02d,%02d,%s\n", (int)
(a + 1),
+dcode, p, c->parm.setup.si1,
+c->parm.setup.si2,
c->parm.setup.eazmsn);
i = isdnloop_writecmd(cbuf, strlen(cbuf), 0,
card);
}
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 19/94] sparc64: don't treat 64-bit syscall return codes as 32-bit
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Dave Kleikamp [ Upstream commit 1535bd8adbdedd60a0ee62e28fd5225d66434371 ] When checking a system call return code for an error, linux_sparc_syscall was sign-extending the lower 32-bit value and comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return codes whose lower 32-bits alone would indicate a failure (such as 4G-1). Use the whole 64-bit value to check for errors. Only the 32-bit path should sign extend the lower 32-bit value. Signed-off-by: Dave Kleikamp Acked-by: Bob Picco Acked-by: Allen Pais Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- arch/sparc/kernel/syscalls.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S index 817187d..557212c 100644 --- a/arch/sparc/kernel/syscalls.S +++ b/arch/sparc/kernel/syscalls.S @@ -184,7 +184,8 @@ linux_sparc_syscall32: mov%i0, %l5! IEU1 5: call%l7 ! CTI Group brk forced srl%i5, 0, %o5 ! IEU1 - ba,a,pt %xcc, 3f + ba,pt %xcc, 3f +sra%o0, 0, %o0 /* Linux native system calls enter here... */ .align 32 @@ -212,7 +213,6 @@ linux_sparc_syscall: 3: stx %o0, [%sp + PTREGS_OFF + PT_V9_I0] ret_sys_call: ldx [%sp + PTREGS_OFF + PT_V9_TSTATE], %g3 - sra %o0, 0, %o0 mov %ulo(TSTATE_XCARRY | TSTATE_ICARRY), %g2 sllx%g2, 32, %g2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 15/94] rds: prevent dereference of a NULL device in rds_iw_laddr_check
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sasha Levin
[ Upstream commit bf39b4247b8799935ea91d90db250ab608a58e50 ]
Binding might result in a NULL device which is later dereferenced
without checking.
Signed-off-by: Sasha Levin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/rds/iw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/rds/iw.c
+++ b/net/rds/iw.c
@@ -239,7 +239,8 @@ static int rds_iw_laddr_check(__be32 add
ret = rdma_bind_addr(cm_id, (struct sockaddr *));
/* due to this, we will claim to support IB devices unless we
check node_type. */
- if (ret || cm_id->device->node_type != RDMA_NODE_RNIC)
+ if (ret || !cm_id->device ||
+ cm_id->device->node_type != RDMA_NODE_RNIC)
ret = -EADDRNOTAVAIL;
rdsdebug("addr %pI4 ret %d node type %d\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/
[PATCH 3.2 03/94] net: unix: non blocking recvmsg() should not return -EINTR
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit de1443916791d75fdd26becb116898277bb0273f ]
Some applications didn't expect recvmsg() on a non blocking socket
could return -EINTR. This possibility was added as a side effect
of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
unix recv routines").
To hit this bug, you need to be a bit unlucky, as the u->readlock
mutex is usually held for very small periods.
Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv
routines")
Signed-off-by: Eric Dumazet
Cc: Rainer Weikusat
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/unix/af_unix.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1771,8 +1771,11 @@ static int unix_dgram_recvmsg(struct kio
goto out;
err = mutex_lock_interruptible(>readlock);
- if (err) {
- err = sock_intr_errno(sock_rcvtimeo(sk, noblock));
+ if (unlikely(err)) {
+ /* recvmsg() in non blocking mode is supposed to return -EAGAIN
+* sk_rcvtimeo is not honored by mutex_lock_interruptible()
+*/
+ err = noblock ? -EAGAIN : -ERESTARTSYS;
goto out;
}
@@ -1887,6 +1890,7 @@ static int unix_stream_recvmsg(struct ki
struct unix_sock *u = unix_sk(sk);
struct sockaddr_un *sunaddr = msg->msg_name;
int copied = 0;
+ int noblock = flags & MSG_DONTWAIT;
int check_creds = 0;
int target;
int err = 0;
@@ -1901,7 +1905,7 @@ static int unix_stream_recvmsg(struct ki
goto out;
target = sock_rcvlowat(sk, flags_WAITALL, size);
- timeo = sock_rcvtimeo(sk, flags_DONTWAIT);
+ timeo = sock_rcvtimeo(sk, noblock);
/* Lock the socket to prevent queue disordering
* while sleeps in memcpy_tomsg
@@ -1913,8 +1917,11 @@ static int unix_stream_recvmsg(struct ki
}
err = mutex_lock_interruptible(>readlock);
- if (err) {
- err = sock_intr_errno(timeo);
+ if (unlikely(err)) {
+ /* recvmsg() in non blocking mode is supposed to return -EAGAIN
+* sk_rcvtimeo is not honored by mutex_lock_interruptible()
+*/
+ err = noblock ? -EAGAIN : -ERESTARTSYS;
goto 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/
[PATCH 3.2 42/94] jffs2: avoid soft-lockup in jffs2_reserve_space_gc()
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Li Zefan
commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.
We triggered soft-lockup under stress test on 2.6.34 kernel.
BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
...
[] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
[] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
[] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
[] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
[] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
[] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
[] (jffs2_write_end+0x198/0x2c0 [jffs2])
[] (generic_file_buffered_write+0x158/0x200)
[] (__generic_file_aio_write+0x3a4/0x414)
[] (generic_file_aio_write+0x5c/0xbc)
[] (do_sync_write+0x98/0xd4)
[] (vfs_write+0xa8/0x150)
[] (sys_write+0x3c/0xc0)]
Fix this by adding a cond_resched() in the while loop.
[a...@linux-foundation.org: don't initialize `ret']
Signed-off-by: Li Zefan
Cc: David Woodhouse
Cc: Artem Bityutskiy
Signed-off-by: Andrew Morton
Signed-off-by: Brian Norris
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
fs/jffs2/nodemgmt.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/fs/jffs2/nodemgmt.c
+++ b/fs/jffs2/nodemgmt.c
@@ -159,19 +159,24 @@ int jffs2_reserve_space(struct jffs2_sb_
int jffs2_reserve_space_gc(struct jffs2_sb_info *c, uint32_t minsize,
uint32_t *len, uint32_t sumsize)
{
- int ret = -EAGAIN;
+ int ret;
minsize = PAD(minsize);
D1(printk(KERN_DEBUG "jffs2_reserve_space_gc(): Requested 0x%x
bytes\n", minsize));
- spin_lock(>erase_completion_lock);
- while(ret == -EAGAIN) {
+ while (true) {
+ spin_lock(>erase_completion_lock);
ret = jffs2_do_reserve_space(c, minsize, len, sumsize);
if (ret) {
D1(printk(KERN_DEBUG "jffs2_reserve_space_gc: looping,
ret is %d\n", ret));
}
+ spin_unlock(>erase_completion_lock);
+
+ if (ret == -EAGAIN)
+ cond_resched();
+ else
+ break;
}
- spin_unlock(>erase_completion_lock);
if (!ret)
ret = jffs2_prealloc_raw_node_refs(c, c->nextblock, 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 12/94] netlink: don't compare the nul-termination in nla_strcmp
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Pablo Neira
[ Upstream commit 8b7b932434f5eee495b91a2804f5b64ebb2bc835 ]
nla_strcmp compares the string length plus one, so it's implicitly
including the nul-termination in the comparison.
int nla_strcmp(const struct nlattr *nla, const char *str)
{
int len = strlen(str) + 1;
...
d = memcmp(nla_data(nla), str, len);
However, if NLA_STRING is used, userspace can send us a string without
the nul-termination. This is a problem since the string
comparison will not match as the last byte may be not the
nul-termination.
Fix this by skipping the comparison of the nul-termination if the
attribute data is nul-terminated. Suggested by Thomas Graf.
Cc: Florian Westphal
Cc: Thomas Graf
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
lib/nlattr.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -299,9 +299,15 @@ int nla_memcmp(const struct nlattr *nla,
*/
int nla_strcmp(const struct nlattr *nla, const char *str)
{
- int len = strlen(str) + 1;
- int d = nla_len(nla) - len;
+ int len = strlen(str);
+ char *buf = nla_data(nla);
+ int attrlen = nla_len(nla);
+ int d;
+ if (attrlen > 0 && buf[attrlen - 1] == '\0')
+ attrlen--;
+
+ d = attrlen - len;
if (d == 0)
d = memcmp(nla_data(nla), str, len);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 13/94] isdnloop: Validate NUL-terminated strings from user.
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: YOSHIFUJI Hideaki / εθ€θ±ζ
[ Upstream commit 77bc6bed7121936bb2e019a8c336075f4c8eef62 ]
Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/isdn/isdnloop/isdnloop.c | 6 ++
1 file changed, 6 insertions(+)
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -1070,6 +1070,12 @@ isdnloop_start(isdnloop_card * card, isd
return -EBUSY;
if (copy_from_user((char *) , (char *) sdefp, sizeof(sdef)))
return -EFAULT;
+
+ for (i = 0; i < 3; i++) {
+ if (!memchr(sdef.num[i], 0, sizeof(sdef.num[i])))
+ return -EINVAL;
+ }
+
spin_lock_irqsave(>isdnloop_lock, flags);
switch (sdef.ptype) {
case ISDN_PTYPE_EURO:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 22/94] drm/i915: quirk invert brightness for Acer Aspire 5336
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit 0f540c3a7cfb91c9d7a19eb0c95c24c5de1197d5 upstream.
Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula
Date: Fri Sep 20 15:05:30 2013 +0300
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
failed and was later reverted in
commit be505f643925e257087247b996cd8ece787c12af
Author: Alexander van Heukelum
Date: Sat Dec 28 21:00:39 2013 +0100
Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"
fix the individual broken machine instead.
Note to backporters:
http://patchwork.freedesktop.org/patch/17837/
is the patch you want for 3.13 and older.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/dub115-w7628c7c710ea51aa110cd4a5...@phx.gbl
Signed-off-by: Jani Nikula
Reviewed-by: Ville SyrjΓ€lΓ€
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8949,6 +8949,9 @@ struct intel_quirk intel_quirks[] = {
/* Acer Aspire 4736Z */
{ 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
+ /* Acer Aspire 5336 */
+ { 0x2a42, 0x1025, 0x048a, quirk_invert_brightness },
+
/* Dell XPS13 HD Sandy Bridge */
{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 41/94] jffs2: remove from wait queue after schedule()
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Li Zefan commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream. @wait is a local variable, so if we don't remove it from the wait queue list, later wake_up() may end up accessing invalid memory. This was spotted by eyes. Signed-off-by: Li Zefan Cc: David Woodhouse Cc: Artem Bityutskiy Signed-off-by: Andrew Morton Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings --- fs/jffs2/nodemgmt.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/jffs2/nodemgmt.c +++ b/fs/jffs2/nodemgmt.c @@ -128,6 +128,7 @@ int jffs2_reserve_space(struct jffs2_sb_ spin_unlock(>erase_completion_lock); schedule(); + remove_wait_queue(>erase_wait, ); } else spin_unlock(>erase_completion_lock); } else if (ret) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips
It should never be NULL because our interface list is up to date,
and even if it does, we'll just crash anyway so we are no better off.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 21d36ee..a391d13 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -793,8 +793,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
ip = peer->ksnp_passive_ips[i];
best_iface = ksocknal_ip2iface(peer->ksnp_ni, ip);
- /* peer passive ips are kept up to date */
- LASSERT(best_iface != NULL);
} else {
/* choose a new interface */
LASSERT (i == peer->ksnp_n_passive_ips);
@@ -835,8 +833,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
peer->ksnp_n_passive_ips = i+1;
}
- LASSERT (best_iface != NULL);
-
/* mark the best matching peer IP used */
j = ksocknal_match_peerip(best_iface, peerips, n_peerips);
peerips[j] = 0;
--
1.9.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 3.2 46/94] virtio_balloon: don't softlockup on huge balloon changes.
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Rusty Russell commit 1f74ef0f2d7d692fcd615621e0e734c3e7771413 upstream. When adding or removing 100G from a balloon: BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367] We have a wait_event_interruptible(), but the condition is always true (more ballooning to do) so we don't ever sleep. We also have a wait_event() for the host to ack, but that is also always true as QEMU is synchronous for balloon operations. Reported-by: Gopesh Kumar Chaudhary Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings --- drivers/virtio/virtio_balloon.c | 6 ++ 1 file changed, 6 insertions(+) --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -271,6 +271,12 @@ static int balloon(void *_vballoon) else if (diff < 0) leak_balloon(vb, -diff); update_balloon_size(vb); + + /* +* For large balloon changes, we could spend a lot of time +* and always have work to do. Be nice if preempt disabled. +*/ + cond_resched(); } return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 31/94] hvc: ensure hvc_init is only ever called once in hvc_console.c
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Paul Gortmaker
commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.
Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
khcvd thread") moved the call of hvc_init from being a device_initcall
into hvc_alloc, and used a non-null hvc_driver as indication of whether
hvc_init had already been called.
The problem with this is that hvc_driver is only assigned a value
at the bottom of hvc_init, and so there is a window where multiple
hvc_alloc calls can be in progress at the same time and hence try
and call hvc_init multiple times. Previously the use of device_init
guaranteed that hvc_init was only called once.
This manifests itself as sporadic instances of two hvc_init calls
racing each other, and with the loser of the race getting -EBUSY
from tty_register_driver() and hence that virtual console fails:
Couldn't register hvc console driver
virtio-ports vport0p1: error -16 allocating hvc for port
Here we add an atomic_t to guarantee we'll never run hvc_init twice.
Cc: Rusty Russell
Cc: Greg Kroah-Hartman
Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
Reported-by: Jim Somerville
Tested-by: Jim Somerville
Signed-off-by: Paul Gortmaker
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/hvc/hvc_console.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -70,6 +71,9 @@ static struct task_struct *hvc_task;
/* Picks up late kicks after list walk but before schedule() */
static int hvc_kicked;
+/* hvc_init is triggered from hvc_alloc, i.e. only when actually used */
+static atomic_t hvc_needs_init __read_mostly = ATOMIC_INIT(-1);
+
static int hvc_init(void);
#ifdef CONFIG_MAGIC_SYSRQ
@@ -825,7 +829,7 @@ struct hvc_struct *hvc_alloc(uint32_t vt
int i;
/* We wait until a driver actually comes along */
- if (!hvc_driver) {
+ if (atomic_inc_not_zero(_needs_init)) {
int err = hvc_init();
if (err)
return ERR_PTR(err);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Lustre Klocwork fixes
This is just splitting big lnet fixes patch from Klocwork static analysis tool into smaller bits. Reworked according to previous comments. Dmitry Eremin (2): staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected Oleg Drokin (2): staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips staging/lustre/lnet: fix potential null pointer dereference drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++-- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c| 4 drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++--- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] staging/lustre/lnet: fix potential null pointer dereference
Pointer 'ni' checked for NULL at line 1569 may be passed to function and may be dereferenced there by passing argument 1 to function 'lnet_ni_notify_locked' at line 1621. found by Klocwork Insight tool Signed-off-by: Oleg Drokin CC: Dmitry Eremin CC: Liang Zhen --- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c index 995f509..926923a 100644 --- a/drivers/staging/lustre/lnet/lnet/router.c +++ b/drivers/staging/lustre/lnet/lnet/router.c @@ -145,7 +145,7 @@ lnet_ni_notify_locked(lnet_ni_t *ni, lnet_peer_t *lp) * NB individual events can be missed; the only guarantee is that you * always get the most recent news */ - if (lp->lp_notifying) + if (lp->lp_notifying || ni == NULL) return; lp->lp_notifying = 1; -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: Remove extra '/' character in events file path
δΊ 2014/4/28 8:14, Namhyung Kim ει:
> Hi xiakaixu,
>
> (Adding Jiri and Boris to CC)
OK.
thanks,
>
>> The array debugfs_known_mountpoints[] will cause extra '/'
>> character output.
>> Remove it.
>>
>> pre:
>> $ perf probe -l
>> /sys/kernel/debug//tracing/uprobe_events file does not exist -
>> please rebuild kernel with CONFIG_UPROBE_EVENTS.
>>
>> post:
>> $ perf probe -l
>> /sys/kernel/debug/tracing/uprobe_events file does not exist -
>> please rebuild kernel with CONFIG_UPROBE_EVENTS.
>
> Looks like all of its callers already provide a '/' after the debugfs
> mountpoint, so
>
> Acked-by: Namhyung Kim
>
> Thanks,
> Namhyung
>
>>
>> Signed-off-by: Xia Kaixu
>> ---
>> tools/lib/api/fs/debugfs.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
>> index 7c43479..a74fba6 100644
>> --- a/tools/lib/api/fs/debugfs.c
>> +++ b/tools/lib/api/fs/debugfs.c
>> @@ -12,8 +12,8 @@
>> char debugfs_mountpoint[PATH_MAX + 1] = "/sys/kernel/debug";
>>
>> static const char * const debugfs_known_mountpoints[] = {
>> -"/sys/kernel/debug/",
>> -"/debug/",
>> +"/sys/kernel/debug",
>> +"/debug",
>> 0,
>> };
>>
>> -- 1.8.5.5
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected
From: Dmitry Eremin
Null pointer 'cp' that comes from line 2544 may be dereferenced
at line 2618.
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 6173e74..9bf6c94 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -2609,13 +2609,17 @@ kiblnd_rejected (kib_conn_t *conn, int reason, void
*priv, int priv_nob)
case IBLND_REJECT_MSG_QUEUE_SIZE:
CERROR("%s rejected: incompatible message queue
depth %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_queue_depth,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_queue_depth :
+ IBLND_MSG_QUEUE_SIZE(rej->ibr_version),
IBLND_MSG_QUEUE_SIZE(conn->ibc_version));
break;
case IBLND_REJECT_RDMA_FRAGS:
CERROR("%s rejected: incompatible # of RDMA
fragments %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_max_frags,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_max_frags :
+ IBLND_RDMA_FRAGS(rej->ibr_version),
IBLND_RDMA_FRAGS(conn->ibc_version));
break;
--
1.9.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 3.2 47/94] ext4: fix partial cluster handling for bigalloc file systems
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Whitney
commit c06344939422bbd032ac967223a7863de57496b5 upstream.
Commit 9cb00419fa, which enables hole punching for bigalloc file
systems, exposed a bug introduced by commit 6ae06ff51e in an earlier
release. When run on a bigalloc file system, xfstests generic/013, 068,
075, 083, 091, 100, 112, 127, 263, 269, and 270 fail with e2fsck errors
or cause kernel error messages indicating that previously freed blocks
are being freed again.
The latter commit optimizes the selection of the starting extent in
ext4_ext_rm_leaf() when hole punching by beginning with the extent
supplied in the path argument rather than with the last extent in the
leaf node (as is still done when truncating). However, the code in
rm_leaf that initially sets partial_cluster to track cluster sharing on
extent boundaries is only guaranteed to run if rm_leaf starts with the
last node in the leaf. Consequently, partial_cluster is not correctly
initialized when hole punching, and a cluster on the boundary of a
punched region that should be retained may instead be deallocated.
Signed-off-by: Eric Whitney
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Ben Hutchings
---
fs/ext4/extents.c | 21 +
1 file changed, 21 insertions(+)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2372,6 +2372,27 @@ ext4_ext_rm_leaf(handle_t *handle, struc
ex_ee_block = le32_to_cpu(ex->ee_block);
ex_ee_len = ext4_ext_get_actual_len(ex);
+ /*
+* If we're starting with an extent other than the last one in the
+* node, we need to see if it shares a cluster with the extent to
+* the right (towards the end of the file). If its leftmost cluster
+* is this extent's rightmost cluster and it is not cluster aligned,
+* we'll mark it as a partial that is not to be deallocated.
+*/
+
+ if (ex != EXT_LAST_EXTENT(eh)) {
+ ext4_fsblk_t current_pblk, right_pblk;
+ long long current_cluster, right_cluster;
+
+ current_pblk = ext4_ext_pblock(ex) + ex_ee_len - 1;
+ current_cluster = (long long)EXT4_B2C(sbi, current_pblk);
+ right_pblk = ext4_ext_pblock(ex + 1);
+ right_cluster = (long long)EXT4_B2C(sbi, right_pblk);
+ if (current_cluster == right_cluster &&
+ EXT4_PBLK_COFF(sbi, right_pblk))
+ *partial_cluster = -right_cluster;
+ }
+
trace_ext4_ext_rm_leaf(inode, start, ex, *partial_cluster);
while (ex >= EXT_FIRST_EXTENT(eh) &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table
From: Dmitry Eremin
Local variable 'hash' is never used
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c
b/drivers/staging/lustre/lnet/lnet/api-ni.c
index 85b8d81..3f1fdaa 100644
--- a/drivers/staging/lustre/lnet/lnet/api-ni.c
+++ b/drivers/staging/lustre/lnet/lnet/api-ni.c
@@ -127,8 +127,7 @@ lnet_create_remote_nets_table(void)
static void
lnet_destroy_remote_nets_table(void)
{
- int i;
- struct list_head*hash;
+ int i;
if (the_lnet.ln_remote_nets_hash == NULL)
return;
@@ -137,7 +136,8 @@ lnet_destroy_remote_nets_table(void)
LASSERT(list_empty(_lnet.ln_remote_nets_hash[i]));
LIBCFS_FREE(the_lnet.ln_remote_nets_hash,
- LNET_REMOTE_NETS_HASH_SIZE * sizeof(*hash));
+ LNET_REMOTE_NETS_HASH_SIZE *
+ sizeof(the_lnet.ln_remote_nets_hash[0]));
the_lnet.ln_remote_nets_hash = NULL;
}
--
1.9.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 3.2 38/94] rtlwifi: rtl8192se: Fix too long disable of IRQs
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.
In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192se.
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
[bwh: Backported to 3.2:
- Adjust context
- Drop change to an error path that we don't have]
Signed-off-by: Ben Hutchings
---
--- a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
@@ -924,7 +924,7 @@ int rtl92se_hw_init(struct ieee80211_hw
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
u8 tmp_byte = 0;
-
+ unsigned long flags;
bool rtstatus = true;
u8 tmp_u1b;
int err = false;
@@ -936,6 +936,16 @@ int rtl92se_hw_init(struct ieee80211_hw
rtlpci->being_init_adapter = true;
+ /* As this function can take a very long time (up to 350 ms)
+* and can be called with irqs disabled, reenable the irqs
+* to let the other devices continue being serviced.
+*
+* It is safe doing so since our own interrupts will only be enabled
+* in a subsequent step.
+*/
+ local_save_flags(flags);
+ local_irq_enable();
+
rtlpriv->intf_ops->disable_aspm(hw);
/* 1. MAC Initialize */
@@ -969,7 +979,8 @@ int rtl92se_hw_init(struct ieee80211_hw
/* 3. Initialize MAC/PHY Config by MACPHY_reg.txt */
if (rtl92s_phy_mac_config(hw) != true) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, ("MAC Config failed\n"));
- return rtstatus;
+ err = rtstatus;
+ goto exit;
}
/* Make sure BB/RF write OK. We should prevent enter IPS. radio off. */
@@ -979,7 +990,8 @@ int rtl92se_hw_init(struct ieee80211_hw
/* 4. Initialize BB After MAC Config PHY_reg.txt, AGC_Tab.txt */
if (rtl92s_phy_bb_config(hw) != true) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG, ("BB Config failed\n"));
- return rtstatus;
+ err = rtstatus;
+ goto exit;
}
/* 5. Initiailze RF RAIO_A.txt RF RAIO_B.txt */
@@ -1015,7 +1027,8 @@ int rtl92se_hw_init(struct ieee80211_hw
if (rtl92s_phy_rf_config(hw) != true) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_DMESG, ("RF Config failed\n"));
- return rtstatus;
+ err = rtstatus;
+ goto exit;
}
/* After read predefined TXT, we must set BB/MAC/RF
@@ -1089,8 +1102,9 @@ int rtl92se_hw_init(struct ieee80211_hw
rtlpriv->cfg->ops->led_control(hw, LED_CTL_POWER_ON);
rtl92s_dm_init(hw);
+exit:
+ local_irq_restore(flags);
rtlpci->being_init_adapter = false;
-
return err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 29/94] mach64: fix cursor when character width is not a multiple of 8 pixels
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Mikulas Patocka
commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream.
This patch fixes the hardware cursor on mach64 when font width is not a
multiple of 8 pixels.
If you load such a font, the cursor is expanded to the next 8-byte
boundary and a part of the next character after the cursor is not
visible.
For example, when you load a font with 12-pixel width, the cursor width
is 16 pixels and when the cursor is displayed, 4 pixels of the next
character are not visible.
The reason is this: atyfb_cursor is called with proper parameters to
load an image that is 12-pixel wide. However, the number is aligned on
the next 8-pixel boundary on the line
"unsigned int width = (cursor->image.width + 7) >> 3;" and the whole
function acts as it is was loading a 16-pixel image.
This patch fixes it so that the value written to the framebuffer is
padded with 0x (the transparent pattern) when the image size it not
a multiple of 8 pixels. The transparent pattern causes that the cursor
will not interfere with the next character.
Signed-off-by: Mikulas Patocka
Signed-off-by: Tomi Valkeinen
Signed-off-by: Ben Hutchings
---
drivers/video/aty/mach64_cursor.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
--- a/drivers/video/aty/mach64_cursor.c
+++ b/drivers/video/aty/mach64_cursor.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include "../fb_draw.h"
#include
@@ -157,24 +158,33 @@ static int atyfb_cursor(struct fb_info *
for (i = 0; i < height; i++) {
for (j = 0; j < width; j++) {
+ u16 l = 0x;
b = *src++;
m = *msk++;
switch (cursor->rop) {
case ROP_XOR:
// Upper 4 bits of mask data
- fb_writeb(cursor_bits_lookup[(b ^ m) >> 4], dst++);
+ l = cursor_bits_lookup[(b ^ m) >> 4] |
// Lower 4 bits of mask
- fb_writeb(cursor_bits_lookup[(b ^ m) & 0x0f],
- dst++);
+ (cursor_bits_lookup[(b ^ m) & 0x0f] << 8);
break;
case ROP_COPY:
// Upper 4 bits of mask data
- fb_writeb(cursor_bits_lookup[(b & m) >> 4], dst++);
+ l = cursor_bits_lookup[(b & m) >> 4] |
// Lower 4 bits of mask
- fb_writeb(cursor_bits_lookup[(b & m) & 0x0f],
- dst++);
+ (cursor_bits_lookup[(b & m) & 0x0f] << 8);
break;
}
+ /*
+* If cursor size is not a multiple of 8 characters
+* we must pad it with transparent pattern (0x).
+*/
+ if ((j + 1) * 8 > cursor->image.width) {
+ l = comp(l, 0x,
+ (1 << ((cursor->image.width & 7) * 2)) - 1);
+ }
+ fb_writeb(l & 0xff, dst++);
+ fb_writeb(l >> 8, dst++);
}
dst += offset;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 24/94] ARM: mm: introduce present, faulting entries for PAGE_NONE
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
commit 26ffd0d43b186b0d5186354da8714a1c2d360df0 upstream.
PROT_NONE mappings apply the page protection attributes defined by _P000
which translate to PAGE_NONE for ARM. These attributes specify an XN,
RDONLY pte that is inaccessible to userspace. However, on kernels
configured without support for domains, such a pte *is* accessible to
the kernel and can be read via get_user, allowing tasks to read
PROT_NONE pages via syscalls such as read/write over a pipe.
This patch introduces a new software pte flag, L_PTE_NONE, that is set
to identify faulting, present entries.
Signed-off-by: Will Deacon
[bwh: Backported to 3.2 as dependency of commit b6ccb9803e90
('ARM: 7954/1: mm: remove remaining domain support from ARMv6'):
- Drop 3-level changes
- Adjust filename, context]
Signed-off-by: Ben Hutchings
---
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -123,6 +123,7 @@
#define L_PTE_USER (_AT(pteval_t, 1) << 8)
#define L_PTE_XN (_AT(pteval_t, 1) << 9)
#define L_PTE_SHARED (_AT(pteval_t, 1) << 10)/* shared(v6),
coherent(xsc3) */
+#define L_PTE_NONE (_AT(pteval_t, 1) << 11)
/*
* These are the memory types, defined to be compatible with
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -74,7 +74,7 @@ extern pgprot_t pgprot_kernel;
#define _MOD_PROT(p, b)__pgprot(pgprot_val(p) | (b))
-#define PAGE_NONE _MOD_PROT(pgprot_user, L_PTE_XN | L_PTE_RDONLY)
+#define PAGE_NONE _MOD_PROT(pgprot_user, L_PTE_XN | L_PTE_RDONLY
| L_PTE_NONE)
#define PAGE_SHARED_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_XN)
#define PAGE_SHARED_EXEC _MOD_PROT(pgprot_user, L_PTE_USER)
#define PAGE_COPY _MOD_PROT(pgprot_user, L_PTE_USER |
L_PTE_RDONLY | L_PTE_XN)
@@ -84,7 +84,7 @@ extern pgprot_t pgprot_kernel;
#define PAGE_KERNEL_MOD_PROT(pgprot_kernel, L_PTE_XN)
#define PAGE_KERNEL_EXEC pgprot_kernel
-#define __PAGE_NONE__pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY |
L_PTE_XN)
+#define __PAGE_NONE__pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY |
L_PTE_XN | L_PTE_NONE)
#define __PAGE_SHARED __pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)
#define __PAGE_SHARED_EXEC __pgprot(_L_PTE_DEFAULT | L_PTE_USER)
#define __PAGE_COPY__pgprot(_L_PTE_DEFAULT | L_PTE_USER |
L_PTE_RDONLY | L_PTE_XN)
@@ -279,7 +279,7 @@ static inline pte_t pte_mkspecial(pte_t
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
- const pteval_t mask = L_PTE_XN | L_PTE_RDONLY | L_PTE_USER;
+ const pteval_t mask = L_PTE_XN | L_PTE_RDONLY | L_PTE_USER | L_PTE_NONE;
pte_val(pte) = (pte_val(pte) & ~mask) | (pgprot_val(newprot) & mask);
return pte;
}
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -166,6 +166,10 @@
tst r1, #L_PTE_YOUNG
tstne r1, #L_PTE_PRESENT
moveq r3, #0
+#ifndef CONFIG_CPU_USE_DOMAINS
+ tstne r1, #L_PTE_NONE
+ movne r3, #0
+#endif
str r3, [r0]
mcr p15, 0, r0, c7, c10, 1 @ flush_pte
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -171,6 +171,10 @@ ENTRY(cpu_v7_set_pte_ext)
tst r1, #L_PTE_YOUNG
tstne r1, #L_PTE_PRESENT
+#ifndef CONFIG_CPU_USE_DOMAINS
+ eorne r1, r1, #L_PTE_NONE
+ tstne r1, #L_PTE_NONE
+#endif
moveq r3, #0
ARM( str r3, [r0, #2048]! )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 68/94] MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume()
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Huacai Chen commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream. The original MIPS hibernate code flushes cache and TLB entries in swsusp_arch_resume(). But they are removed in Commit 44eeab67416711 (MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross- CPU flush is surely unnecessary because all but the local CPU have already been disabled. But a local flush (at least the TLB flush) is needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is very easy to produce a kernel panic (kernel page fault, or unaligned access). The root cause is E1000E driver use vzalloc_node() to allocate pages, the stale TLB entries of the booting kernel will be misused by the resumed target kernel. Signed-off-by: Huacai Chen Cc: John Crispin Cc: Steven J. Hill Cc: Aurelien Jarno Cc: linux-m...@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/6643/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings --- arch/mips/power/hibernate.S | 1 + 1 file changed, 1 insertion(+) --- a/arch/mips/power/hibernate.S +++ b/arch/mips/power/hibernate.S @@ -44,6 +44,7 @@ LEAF(swsusp_arch_resume) bne t1, t3, 1b PTR_L t0, PBE_NEXT(t0) bnez t0, 0b + jal local_flush_tlb_all /* Avoid TLB mismatch after kernel resume */ PTR_LA t0, saved_regs PTR_L ra, PT_R31(t0) PTR_L sp, PT_R29(t0) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock
On Fri, 2014-04-25 at 09:59 -0400, Alan Stern wrote: > On Fri, 25 Apr 2014, Li Zhong wrote: > > > > No, this isn't self removal. The driver-attribute (not device-attribute) > > > store operation simply grabs a lock that is also held while the driver > > > is being deregistered at module unload. Taking a reference to the module > > > in this case will prevent deregistration while store is running. > > > > > > But it seems like this can be solved for usb-serial by simply not > > > holding the lock while deregistering. > > > > I didn't look carefully about this lock. > > > > But I'm not sure whether there are such requirements for driver > > attributes: > > > > some lock needs be grabbed in the driver attributes store callbacks, and > > the same lock also needs to be grabbed during driver unregister. > > In this case, the lock does _not_ need to be grabbed during driver > unregister. The driver grabs the lock, but it doesn't need to. OK. > > > If we have such requirements currently or in the future, I think they > > could all be solved by breaking active protection after get the module > > reference. > > No! That would be very bad. > > Unloading modules is quite different from unbinding drivers. After the > driver is unbound, its attribute callback routines can continue to run. > But after a driver module has been unloaded, its attribute callback > routines _cannot_ run because they aren't present in memory any more. > > If we allowed a module to be unloaded while one of its callbacks was > running (because active protection was broken), imagine what would > happen... I don't think the module could be unloaded after we increased the module reference counter. Thanks, Zhong > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 08/12] ACPI: introduce dummy lpss scan handler
On Mon, 2014-04-28 at 00:23 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 08, 2014 12:06:55 AM Zhang Rui wrote:
> > When the lpss scan handler is compiled out, aka, CONFIG_X86_INTEL_LPSS
> > is cleared, those ACPI device objects will be recgonized as regular
> > _HID devices, and a platform device would be created for each of them.
> > This is wrong because the platform drivers for those devices would
> > be loaded, but with broken behavior.
> >
> > In order to fix this, a dummy lpss scan handler is introduced
> > to prevent those platform devices from being created.
> > Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.
> >
> > Signed-off-by: Zhang Rui
>
> All of the patches adding dummy scan handlers should go before [7/12] I think.
>
agreed, will do it in next version.
thanks,
rui
> > ---
> > drivers/acpi/Makefile|2 +-
> > drivers/acpi/acpi_lpss.c | 69
> > --
> > drivers/acpi/internal.h |4 ---
> > 3 files changed, 50 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > index 9a43893..2173e30 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -39,7 +39,7 @@ acpi-y+= processor_core.o
> > acpi-y += ec.o
> > acpi-$(CONFIG_ACPI_DOCK) += dock.o
> > acpi-y += pci_root.o pci_link.o pci_irq.o
> > -acpi-$(CONFIG_X86_INTEL_LPSS) += acpi_lpss.o
> > +acpi-y += acpi_lpss.o
> > acpi-y += acpi_platform.o
> > acpi-y += acpi_pnp.o
> > acpi-y += power.o
> > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> > index 69e29f4..965428f 100644
> > --- a/drivers/acpi/acpi_lpss.c
> > +++ b/drivers/acpi/acpi_lpss.c
> > @@ -24,6 +24,8 @@
> >
> > ACPI_MODULE_NAME("acpi_lpss");
> >
> > +#ifdef CONFIG_X86_INTEL_LPSS
> > +
> > #define LPSS_CLK_SIZE 0x04
> > #define LPSS_LTR_SIZE 0x18
> >
> > @@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
> > .shared_clock = _clock,
> > };
> >
> > +#define LPSS_PTR(desc) ((unsigned long))
> > +
> > +#else
> > +
> > +#define LPSS_PTR(desc) 0
> > +
> > +#endif
> > +
> > static const struct acpi_device_id acpi_lpss_device_ids[] = {
> > /* Generic LPSS devices */
> > - { "INTL9C60", (unsigned long)_dma_desc },
> > + { "INTL9C60", LPSS_PTR(lpss_dma_desc) },
> >
> > /* Lynxpoint LPSS devices */
> > - { "INT33C0", (unsigned long)_dev_desc },
> > - { "INT33C1", (unsigned long)_dev_desc },
> > - { "INT33C2", (unsigned long)_dev_desc },
> > - { "INT33C3", (unsigned long)_dev_desc },
> > - { "INT33C4", (unsigned long)_uart_dev_desc },
> > - { "INT33C5", (unsigned long)_uart_dev_desc },
> > - { "INT33C6", (unsigned long)_sdio_dev_desc },
> > + { "INT33C0", LPSS_PTR(lpt_dev_desc) },
> > + { "INT33C1", LPSS_PTR(lpt_dev_desc) },
> > + { "INT33C2", LPSS_PTR(lpt_dev_desc) },
> > + { "INT33C3", LPSS_PTR(lpt_dev_desc) },
> > + { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
> > + { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
> > + { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
> > { "INT33C7", },
> >
> > /* BayTrail LPSS devices */
> > - { "80860F09", (unsigned long)_pwm_dev_desc },
> > - { "80860F0A", (unsigned long)_uart_dev_desc },
> > - { "80860F0E", (unsigned long)_spi_dev_desc },
> > - { "80860F14", (unsigned long)_sdio_dev_desc },
> > - { "80860F41", (unsigned long)_i2c_dev_desc },
> > + { "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
> > + { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
> > + { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
> > + { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
> > + { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
> > { "INT33B2", },
> >
> > - { "INT3430", (unsigned long)_dev_desc },
> > - { "INT3431", (unsigned long)_dev_desc },
> > - { "INT3432", (unsigned long)_dev_desc },
> > - { "INT3433", (unsigned long)_dev_desc },
> > - { "INT3434", (unsigned long)_uart_dev_desc },
> > - { "INT3435", (unsigned long)_uart_dev_desc },
> > - { "INT3436", (unsigned long)_sdio_dev_desc },
> > + { "INT3430", LPSS_PTR(lpt_dev_desc) },
> > + { "INT3431", LPSS_PTR(lpt_dev_desc) },
> > + { "INT3432", LPSS_PTR(lpt_dev_desc) },
> > + { "INT3433", LPSS_PTR(lpt_dev_desc) },
> > + { "INT3434", LPSS_PTR(lpt_uart_dev_desc) },
> > + { "INT3435", LPSS_PTR(lpt_uart_dev_desc) },
> > + { "INT3436", LPSS_PTR(lpt_sdio_dev_desc) },
> > { "INT3437", },
> >
> > { }
> > };
> >
> > +#ifdef CONFIG_X86_INTEL_LPSS
> > +
> > static int is_memory(struct acpi_resource *res, void *not_used)
> > {
> > struct resource r;
> > @@ -511,10 +523,27 @@ static struct acpi_scan_handler lpss_handler = {
> > .unbind = acpi_lpss_unbind,
> > };
> >
> > +#endif /* CONFIG_X86_INTEL_LPSS */
> >
[PATCH 3.2 44/94] jffs2: Fix crash due to truncation of csize
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Ajesh Kunhipurayil Vijayan commit 41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream. mounting JFFS2 partition sometimes crashes with this call trace: [ 1322.24] Kernel bug detected[#1]: [ 1322.244000] Cpu 2 [ 1322.244000] $ 0 : 0018 3ff00070 0001 [ 1322.252000] $ 4 : c000f3980150 0001 [ 1322.26] $ 8 : c09cd5f8 0001 0088 c000ed300de8 [ 1322.268000] $12 : e5e19d9c5f613a45 c046d464 66227ba5ea67b74e [ 1322.276000] $16 : c000f1769c00 c000ed1e0200 c000f3980150 [ 1322.284000] $20 : c000f3a8 fffc c000ed2cfbd8 c000f39818f0 [ 1322.292000] $24 : 0004 [ 1322.30] $28 : c000ed2c c000ed2cfab8 0001 c039c0b0 [ 1322.308000] Hi: 023c [ 1322.312000] Lo: 0003f802 [ 1322.316000] epc : c039a9f8 check_tn_node+0x88/0x3b0 [ 1322.32] Not tainted [ 1322.324000] ra: c039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.332000] Status: 5400f8e3KX SX UX KERNEL EXL IE [ 1322.336000] Cause : 00800034 [ 1322.34] PrId : 000c1004 (Netlogic XLP) [ 1322.344000] Modules linked in: [ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c000ed2c, task=c000f0e68dd8, tls=) [ 1322.356000] Stack : c000f1769e30 c000ed010780 c000ed010780 c000ed30 c000f1769c00 c000f3980150 c000f3a8 fffc c000ed2cfbd8 c039c0b0 c09c6340 1000 0dec c016c9d8 c000f39805a0 c000f3980180 0086 00010dec c000f1769d98 c000ed2cfb18 0001 0001 0044 c000f3a8 c000f1769c00 c000f3d207a8 c000f1769d98 c000f1769de0 c076f9c0 0009 c039cf90 0017 c013fbdc 0001 00010003e61c ... [ 1322.424000] Call Trace: [ 1322.428000] [] check_tn_node+0x88/0x3b0 [ 1322.432000] [] jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.44] [] jffs2_do_crccheck_inode+0x70/0xd0 [ 1322.448000] [] jffs2_garbage_collect_pass+0x160/0x870 [ 1322.452000] [] jffs2_garbage_collect_thread+0xdc/0x1f0 [ 1322.46] [] kthread+0xb8/0xc0 [ 1322.464000] [] kernel_thread_helper+0x10/0x18 [ 1322.472000] [ 1322.472000] Code: 67bd0050 94a4002c 2c830001 <00038036> de050218 2403fffc 0080a82d 00431824 24630044 [ 1322.48] ---[ end trace b052bb90e97dfbf5 ]--- The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it is used to hold the compressed data length(csize) which is declared as uint32_t. So, when the value of csize exceeds 16bits, it gets truncated when assigned to tn->csize. This is causing a kernel BUG. Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue. Signed-off-by: Ajesh Kunhipurayil Vijayan Signed-off-by: Kamlakant Patel Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings --- fs/jffs2/nodelist.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/jffs2/nodelist.h +++ b/fs/jffs2/nodelist.h @@ -231,7 +231,7 @@ struct jffs2_tmp_dnode_info uint32_t version; uint32_t data_crc; uint32_t partial_crc; - uint16_t csize; + uint32_t csize; uint16_t overlapped; }; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 43/94] jffs2: Fix segmentation fault found in stress test
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Kamlakant Patel
commit 3367da5610c50e6b83f86d366d72b41b350b06a2 upstream.
Creating a large file on a JFFS2 partition sometimes crashes with this call
trace:
[ 306.476000] CPU 13 Unable to handle kernel paging request at virtual address
c000dfff8002, epc == c03a80a8, ra == c03a8044
[ 306.488000] Oops[#1]:
[ 306.488000] Cpu 13
[ 306.492000] $ 0 : 8008
8007
[ 306.50] $ 4 : c000dfff8002 009f c000e0007cde
c000ee95fa58
[ 306.508000] $ 8 : 0001 8008 0001
8002
[ 306.516000] $12 : 7fa9 ff0e ff0f
80e55930aebb92bb
[ 306.524000] $16 : c000e000 c000ee95fa5c c000efc8
c09edd70
[ 306.532000] $20 : c2b6 c000ee95fa58
c000efc8
[ 306.54] $24 : 0004
[ 306.548000] $28 : c000ee95 c000ee95f738
c03a8044
[ 306.556000] Hi: 000574a5
[ 306.56] Lo: 6193b7a7e903d8c9
[ 306.564000] epc : c03a80a8 jffs2_rtime_compress+0x98/0x198
[ 306.568000] Tainted: GW
[ 306.572000] ra: c03a8044 jffs2_rtime_compress+0x34/0x198
[ 306.58] Status: 5000f8e3KX SX UX KERNEL EXL IE
[ 306.584000] Cause : 0088
[ 306.588000] BadVA : c000dfff8002
[ 306.592000] PrId : 000c1100 (Netlogic XLP)
[ 306.596000] Modules linked in:
[ 306.596000] Process dd (pid: 170, threadinfo=c000ee95,
task=c000ee6e0858, tls=00c47490)
[ 306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4
7e7d7f817f487f5f
7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7
7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb
7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93
7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64
7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53
7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80
7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3
7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6
7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9
...
[ 306.676000] Call Trace:
[ 306.68] [] jffs2_rtime_compress+0x98/0x198
[ 306.684000] [] jffs2_selected_compress+0x110/0x230
[ 306.692000] [] jffs2_compress+0x5c/0x388
[ 306.696000] [] jffs2_write_inode_range+0xd8/0x388
[ 306.704000] [] jffs2_write_end+0x16c/0x2d0
[ 306.708000] [] generic_file_buffered_write+0xf8/0x2b8
[ 306.716000] [] __generic_file_aio_write+0x1ac/0x350
[ 306.72] [] generic_file_aio_write+0x80/0x168
[ 306.728000] [] do_sync_write+0x94/0xf8
[ 306.732000] [] vfs_write+0xa4/0x1a0
[ 306.736000] [] SyS_write+0x50/0x90
[ 306.744000] [] handle_sys+0x180/0x1a0
[ 306.748000]
[ 306.748000]
Code: 020b202d 0205282d 90a5 <9084> 14a40038 0060602d
282d 016c5823
[ 306.76] ---[ end trace 79dd088435be02d0 ]---
Segmentation fault
This crash is caused because the 'positions' is declared as an array of signed
short. The value of position is in the range 0..65535, and will be converted
to a negative number when the position is greater than 32767 and causes a
corruption and crash. Changing the definition to 'unsigned short' fixes this
issue
Signed-off-by: Jayachandran C
Signed-off-by: Kamlakant Patel
Signed-off-by: Brian Norris
Signed-off-by: Ben Hutchings
---
fs/jffs2/compr_rtime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/jffs2/compr_rtime.c
+++ b/fs/jffs2/compr_rtime.c
@@ -33,7 +33,7 @@ static int jffs2_rtime_compress(unsigned
unsigned char *cpage_out,
uint32_t *sourcelen, uint32_t *dstlen)
{
- short positions[256];
+ unsigned short positions[256];
int outpos = 0;
int pos=0;
@@ -74,7 +74,7 @@ static int jffs2_rtime_decompress(unsign
unsigned char *cpage_out,
uint32_t srclen, uint32_t destlen)
{
- short positions[256];
+ unsigned short positions[256];
int outpos = 0;
int pos=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 3.2 54/94] mfd: max8925: Fix possible NULL pointer dereference on i2c_new_dummy error
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Krzysztof Kozlowski
commit 96cf3dedc491d2f1f66cc26217f2b06b0c7b6797 upstream.
During probe the driver allocates dummy I2C devices for RTC and ADC
with i2c_new_dummy() but it does not check the return value of this
calls.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC or ADC devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Lee Jones
Signed-off-by: Ben Hutchings
---
drivers/mfd/max8925-i2c.c | 9 +
1 file changed, 9 insertions(+)
--- a/drivers/mfd/max8925-i2c.c
+++ b/drivers/mfd/max8925-i2c.c
@@ -156,9 +156,18 @@ static int __devinit max8925_probe(struc
mutex_init(>io_lock);
chip->rtc = i2c_new_dummy(chip->i2c->adapter, RTC_I2C_ADDR);
+ if (!chip->rtc) {
+ dev_err(chip->dev, "Failed to allocate I2C device for RTC\n");
+ return -ENODEV;
+ }
i2c_set_clientdata(chip->rtc, chip);
chip->adc = i2c_new_dummy(chip->i2c->adapter, ADC_I2C_ADDR);
+ if (!chip->adc) {
+ dev_err(chip->dev, "Failed to allocate I2C device for ADC\n");
+ i2c_unregister_device(chip->rtc);
+ return -ENODEV;
+ }
i2c_set_clientdata(chip->adc, chip);
max8925_device_init(chip, pdata);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 45/94] iwlwifi: dvm: take mutex when sending SYNC BT config command
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Emmanuel Grumbach commit 82e5a649453a3cf23516277abb84273768a1592b upstream. There is a flow in which we send the host command in SYNC mode, but we don't take priv->mutex. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495 Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach [bwh: Backported to 3.2: - Adjust filename, context - mutex is priv->shrd->mutex] Signed-off-by: Ben Hutchings --- drivers/net/wireless/iwlwifi/iwl-agn.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -246,13 +246,17 @@ static void iwl_bg_bt_runtime_config(str struct iwl_priv *priv = container_of(work, struct iwl_priv, bt_runtime_config); + mutex_lock(>shrd->mutex); if (test_bit(STATUS_EXIT_PENDING, >shrd->status)) - return; + goto out; /* dont send host command if rf-kill is on */ if (!iwl_is_ready_rf(priv->shrd)) - return; + goto out; + iwlagn_send_advance_bt_config(priv); +out: + mutex_unlock(>shrd->mutex); } static void iwl_bg_bt_full_concurrency(struct work_struct *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/
Re: [PATCH V5 09/12] ACPI: introduce acpi platform exclude id list
On Mon, 2014-04-28 at 00:21 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 08, 2014 12:06:56 AM Zhang Rui wrote:
> > For ACPI PIC (PNP) and Timer (PNP0100) device objects, although
> > they have _HID control method, but they should not be enumerated to
> > platform bus, because there will never be any platform drivers for them.
> >
> > Thus an exclude id list is introduced in this patch to prevent
> > those platform device nodes from being created.
> >
> > Signed-off-by: Zhang Rui
>
> This should go into [6/12] as well.
>
I think it is okay to keep them as separate patches because they do not
break bisect. And this patch is just a cleanup, it does not fix a real
BUG in patch 6/12.
thanks,
rui
> > ---
> > drivers/acpi/acpi_platform.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> > index 33376a9..91ed43a 100644
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -22,6 +22,17 @@
> >
> > ACPI_MODULE_NAME("platform");
> >
> > +static const struct acpi_device_id excluded_id_list[] = {
> > + {"PNP", 0}, /* PIC */
> > + {"PNP0100", 0}, /* Timer */
> > + {"", 0},
> > +};
> > +
> > +static bool is_exclusive_device(struct acpi_device *dev)
> > +{
> > + return !acpi_match_device_ids(dev, excluded_id_list);
> > +}
> > +
> > /**
> > * acpi_create_platform_device - Create platform device for ACPI device
> > node
> > * @adev: ACPI device node to create a platform device for.
> > @@ -48,6 +59,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
> > if (adev->physical_node_count)
> > return 0;
> >
> > + if (is_exclusive_device(adev))
> > + return 0;
> > +
> > INIT_LIST_HEAD(_list);
> > count = acpi_dev_get_resources(adev, _list, NULL, NULL);
> > if (count < 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 3.2 57/94] audit: convert PPIDs to the inital PID namespace.
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Richard Guy Briggs
commit c92cdeb45eea38515e82187f48c2e4f435fb4e25 upstream.
sys_getppid() returns the parent pid of the current process in its own pid
namespace. Since audit filters are based in the init pid namespace, a process
could avoid a filter or trigger an unintended one by being in an alternate pid
namespace or log meaningless information.
Switch to task_ppid_nr() for PPIDs to anchor all audit filters in the
init_pid_ns.
(informed by ebiederman's 6c621b7e)
Cc: Eric W. Biederman
Signed-off-by: Richard Guy Briggs
[bwh: Backported to 3.2: sys_getppid() is used by audit_exit() but not
audit_log_task_info()]
Signed-off-by: Ben Hutchings
---
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -473,7 +473,7 @@ static int audit_filter_rules(struct tas
case AUDIT_PPID:
if (ctx) {
if (!ctx->ppid)
- ctx->ppid = sys_getppid();
+ ctx->ppid = task_ppid_nr(tsk);
result = audit_comparator(ctx->ppid, f->op,
f->val);
}
break;
@@ -1335,7 +1335,7 @@ static void audit_log_exit(struct audit_
/* tsk == current */
context->pid = tsk->pid;
if (!context->ppid)
- context->ppid = sys_getppid();
+ context->ppid = task_ppid_nr(tsk);
cred = current_cred();
context->uid = cred->uid;
context->gid = cred->gid;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 56/94] pid: get pid_t ppid of task in init_pid_ns
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Richard Guy Briggs
commit ad36d28293936b03d6b7996e9d6aadfd73c0eb08 upstream.
Added the functions task_ppid_nr_ns() and task_ppid_nr() to abstract the lookup
of the PPID (real_parent's pid_t) of a process, including rcu locking, in the
arbitrary and init_pid_ns.
This provides an alternative to sys_getppid(), which is relative to the child
process' pid namespace.
(informed by ebiederman's 6c621b7e)
Cc: Eric W. Biederman
Signed-off-by: Richard Guy Briggs
Signed-off-by: Ben Hutchings
---
include/linux/sched.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1690,6 +1690,24 @@ static inline pid_t task_tgid_vnr(struct
}
+static int pid_alive(const struct task_struct *p);
+static inline pid_t task_ppid_nr_ns(const struct task_struct *tsk, struct
pid_namespace *ns)
+{
+ pid_t pid = 0;
+
+ rcu_read_lock();
+ if (pid_alive(tsk))
+ pid = task_tgid_nr_ns(rcu_dereference(tsk->real_parent), ns);
+ rcu_read_unlock();
+
+ return pid;
+}
+
+static inline pid_t task_ppid_nr(const struct task_struct *tsk)
+{
+ return task_ppid_nr_ns(tsk, _pid_ns);
+}
+
static inline pid_t task_pgrp_nr_ns(struct task_struct *tsk,
struct pid_namespace *ns)
{
@@ -1727,7 +1745,7 @@ static inline pid_t task_pgrp_nr(struct
* If pid_alive fails, then pointers within the task structure
* can be stale and must not be dereferenced.
*/
-static inline int pid_alive(struct task_struct *p)
+static inline int pid_alive(const struct task_struct *p)
{
return p->pids[PIDTYPE_PID].pid != NULL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock
On Fri, 2014-04-25 at 09:54 -0400, Alan Stern wrote: > On Fri, 25 Apr 2014, Li Zhong wrote: > > > > I don't get why try_module_get() matters here. We can't call into > > > ->store if the object at hand is already destroyed and the underlying > > > module can't go away if the target device is still alive. > > > try_module_get() doesn't actually protect the object. Why does that > > > matter? This is self removal, right? Can you please take a look at > > > kernfs_remove_self()? > > > > This is about one process writing something to driver attributes, and > > one process trying to unload this driver. > > > > I think try_module_get() could detect whether the driver is being > > unloaded, and if not, prevent it from being unloaded, so it could > > protect the object here by not allow the driver to be unloaded. > > That isn't how try_module_get() works. If the module is being > unloaded, try_module_get() simply fails. It does not prevent the > module from being unloaded -- that's why its name begins with "try". Yes, I know that. What I said above is for the case when try_module_get() detects the driver is NOT being unloaded, and increases the reference counter. Thanks, Zhong > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 40/94] Btrfs: skip submitting barrier for missing device
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Hidetoshi Seto
commit f88ba6a2a44ee98e8d59654463dc157bb6d13c43 upstream.
I got an error on v3.13:
BTRFS error (device sdf1) in write_all_supers:3378: errno=-5 IO failure
(errors while submitting device barriers.)
how to reproduce:
> mkfs.btrfs -f -d raid1 /dev/sdf1 /dev/sdf2
> wipefs -a /dev/sdf2
> mount -o degraded /dev/sdf1 /mnt
> btrfs balance start -f -sconvert=single -mconvert=single -dconvert=single
/mnt
The reason of the error is that barrier_all_devices() failed to submit
barrier to the missing device. However it is clear that we cannot do
anything on missing device, and also it is not necessary to care chunks
on the missing device.
This patch stops sending/waiting barrier if device is missing.
Signed-off-by: Hidetoshi Seto
Signed-off-by: Josef Bacik
Signed-off-by: Ben Hutchings
---
fs/btrfs/disk-io.c | 4
1 file changed, 4 insertions(+)
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2731,6 +2731,8 @@ static int barrier_all_devices(struct bt
/* send down all the barriers */
head = >fs_devices->devices;
list_for_each_entry_rcu(dev, head, dev_list) {
+ if (dev->missing)
+ continue;
if (!dev->bdev) {
errors++;
continue;
@@ -2745,6 +2747,8 @@ static int barrier_all_devices(struct bt
/* wait for all the barriers */
list_for_each_entry_rcu(dev, head, dev_list) {
+ if (dev->missing)
+ continue;
if (!dev->bdev) {
errors++;
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
