[PATCH v9 0/4] Add generic driver for on-chip SRAM
These patches add support to configure on-chip SRAM via device-tree
node or platform data and to obtain the resulting genalloc pool from
the struct device pointer or a phandle pointing at the device tree node.
This allows drivers to allocate SRAM with the genalloc API without
hard-coding the genalloc pool pointer.
The on-chip SRAM on i.MX53 and i.MX6q can be registered via device tree
and changed to use the simple generic SRAM driver:
ocram: ocram@0090 {
compatible = "fsl,imx-ocram", "mmio-sram";
reg = <0x0090 0x3f000>;
};
A driver that needs to allocate SRAM buffers, like the video processing
unit on i.MX53, can retrieve the genalloc pool from a phandle in the
device tree using of_get_named_gen_pool(node, "iram", 0) from patch 1:
vpu@63ff4000 {
/* ... */
iram = <>;
};
Changes since v8:
- The sram driver now matches against the "mmio-sram" compatible string.
- Removed a whitespace error in the device tree binding documentation.
regards
Philipp
---
Documentation/devicetree/bindings/media/coda.txt | 30 ++
Documentation/devicetree/bindings/misc/sram.txt | 16 +++
arch/arm/boot/dts/imx53.dtsi |5 +
arch/arm/boot/dts/imx6q.dtsi |6 ++
drivers/media/platform/Kconfig |1 -
drivers/media/platform/coda.c| 45 +---
drivers/misc/Kconfig |9 ++
drivers/misc/Makefile|1 +
drivers/misc/sram.c | 121 ++
include/linux/genalloc.h | 15 +++
include/linux/platform_data/coda.h | 18
lib/genalloc.c | 81 +++
12 files changed, 333 insertions(+), 15 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/
[PATCH v9 2/4] misc: Generic on-chip SRAM allocation driver
This driver requests and remaps a memory region as configured in the
device tree. It serves memory from this region via the genalloc API.
It optionally enables the SRAM clock.
Other drivers can retrieve the genalloc pool from a phandle pointing
to this drivers' device node in the device tree.
The allocation granularity is hard-coded to 32 bytes for now,
to make the SRAM driver useful for the 6502 remoteproc driver.
There is overhead for bigger SRAMs, where only a much coarser
allocation granularity is needed: At 32 bytes minimum allocation
size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations.
Signed-off-by: Philipp Zabel
Reviewed-by: Shawn Guo
Acked-by: Grant Likely
---
Changes since v8:
- Changed device tree compatible string to "mmio-sram"
---
Documentation/devicetree/bindings/misc/sram.txt | 16 +++
drivers/misc/Kconfig|9 ++
drivers/misc/Makefile |1 +
drivers/misc/sram.c | 121 +++
4 files changed, 147 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/sram.txt
create mode 100644 drivers/misc/sram.c
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/misc/sram.txt
new file mode 100644
index 000..4d0a00e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -0,0 +1,16 @@
+Generic on-chip SRAM
+
+Simple IO memory regions to be managed by the genalloc API.
+
+Required properties:
+
+- compatible : mmio-sram
+
+- reg : SRAM iomem address range
+
+Example:
+
+sram: sram@5c00 {
+ compatible = "mmio-sram";
+ reg = <0x5c00 0x4>; /* 256 KiB SRAM at address 0x5c00 */
+};
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..4878507 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -510,6 +510,15 @@ config LATTICE_ECP3_CONFIG
If unsure, say N.
+config SRAM
+ bool "Generic on-chip SRAM driver"
+ depends on HAS_IOMEM
+ select GENERIC_ALLOCATOR
+ help
+ This driver allows to declare a memory region to be managed
+ by the genalloc API. It is supposed to be used for small
+ on-chip SRAM areas found on many SoCs.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..08e2007 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
+obj-$(CONFIG_SRAM) += sram.o
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
new file mode 100644
index 000..7858c62
--- /dev/null
+++ b/drivers/misc/sram.c
@@ -0,0 +1,121 @@
+/*
+ * Generic on-chip SRAM allocation driver
+ *
+ * Copyright (C) 2012 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SRAM_GRANULARITY 32
+
+struct sram_dev {
+ struct gen_pool *pool;
+ struct clk *clk;
+};
+
+static int sram_probe(struct platform_device *pdev)
+{
+ void __iomem *virt_base;
+ struct sram_dev *sram;
+ struct resource *res;
+ unsigned long size;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ size = resource_size(res);
+
+ virt_base = devm_request_and_ioremap(>dev, res);
+ if (!virt_base)
+ return -EADDRNOTAVAIL;
+
+ sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
+ if (!sram)
+ return -ENOMEM;
+
+ sram->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(sram->clk))
+ sram->clk = NULL;
+ else
+ clk_prepare_enable(sram->clk);
+
+ sram->pool = devm_gen_pool_create(>dev, ilog2(SRAM_GRANULARITY),
-1);
+ if (!sram->pool)
+ return -ENOMEM;
+
+ ret = gen_pool_add_virt(sram->pool, (unsigned
[PATCH v9 4/4] ARM: dts: add sram for imx53 and imx6q
Signed-off-by: Philipp Zabel
Reviewed-by: Shawn Guo
Acked-by: Grant Likely
---
Changes since v8:
- Changed device tree compatible string to "mmio-sram"
---
arch/arm/boot/dts/imx53.dtsi |5 +
arch/arm/boot/dts/imx6q.dtsi |6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index edc3f1e..69d0680 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -664,5 +664,10 @@
status = "disabled";
};
};
+
+ ocram: ocram@f800 {
+ compatible = "fsl,imx-ocram", "mmio-sram";
+ reg = <0xf800 0x2>;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ff1205e..73302db 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -124,6 +124,12 @@
status = "disabled";
};
+ ocram: ocram@0090 {
+ compatible = "fsl,imx-ocram", "mmio-sram";
+ reg = <0x0090 0x3f000>;
+ clocks = < 142>;
+ };
+
timer@00a00600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x00a00600 0x20>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 08/18] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking"
On Wed, Feb 13, 2013 at 7:23 AM, Alex Shi wrote: > On 02/12/2013 06:27 PM, Peter Zijlstra wrote: >> On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >>> Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then >>> we can use runnable load variables. >>> >> It would be nice if we could quantify the performance hit of doing so. >> Haven't yet looked at later patches to see if we remove anything to >> off-set this. >> > > In our rough testing, no much clear performance changes. > I'd personally like this to go with a series that actually does something with it. There's been a few proposals floating around on _how_ to do this; but the challenge is in getting it stable enough that all of the wake-up balancing does not totally perforate your stability gains into the noise. select_idle_sibling really is your nemesis here. It's a small enough patch that it can go at the head of any such series (and indeed; it was originally structured to make such a patch rather explicit.) > -- > Thanks > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] virt_mmio: fix signature checking for BE guests
On Wed, 2013-02-13 at 15:28 +, Marc Zyngier wrote: > >> Fix it by encoding the magic as an integer instead of a string. > >> So I'm not completely sure this is the right fix, > > > > It seems right, however... > > > >> - Using __raw_readl() instead. Is that a generic enough API? > >> > > ... this implies that either the spec is wrong (as it should say: the > > device registers are always LE, in the PCI spirit) or all readl()s & co. > > should be replaced with __raw equivalents. > > Well, the spec clearly says that the registers reflect the endianess of > the guest, and it makes sense: when performing the MMIO access, KVM > needs to convert between host and guest endianess. The virtio-mmio spec says so because it seemed like a good idea at the time ;-) after reading the PCI device spec. But - as I said - I missed the fact that the readl()-like accessors will always do le32_to_cpu(). Apparently ioread32() does the same (there's a separate ioread32be()). So I'm not sure that the spec is correct in this aspect any more. Maybe it should specify the registers as LE always, similarly to PCI? This problem is already covered by "2.3.1 A Note on Virtqueue Endianness" in the spec... > > Having said that, does the change make everything else work with a BE > > guest? (I assume we're talking about the guest being BE, right? ;-) If > > so it means that the host is not following the current spec and it > > treats all the registers as LE. > > Yes, I only care about a BE guest. And no, not much is actually working > (kvmtool is not happy about the guest addresses it finds in the > virtio-ring). Need to dive into it and understand what needs to be fixed... Do the other registers like queuenum make sense? Could it be that the page number of the ring you're getting has wrong endianness? Paweł -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 07/18] sched: set initial load avg of new forked task
On Wed, Feb 13, 2013 at 7:14 AM, Alex Shi wrote: > On 02/12/2013 06:26 PM, Peter Zijlstra wrote: >> On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >>> + /* >>> +* set the initial load avg of new task same as its load >>> +* in order to avoid brust fork make few cpu too heavier >>> +*/ >>> + if (flags & ENQUEUE_NEWTASK) >>> + se->avg.load_avg_contrib = se->load.weight; >> >> I seem to have vague recollections of a discussion with pjt where we >> talk about the initial behaviour of tasks; from this haze I had the >> impression that new tasks should behave like full weight.. >> > > Here just make the new task has full weight.. > >> PJT is something more fundamental screwy? >> So tasks get the quotient of their runnability over the period. Given the period initially is equivalent to runnability it's definitely the *intent* to start at full-weight and ramp-down. Thinking on it, perhaps this is running a-foul of amortization -- in that we only recompute this quotient on each 1024ns boundary; perhaps in the fork-bomb case we're too slow to accumulate these. Alex, does something like the following help? This would force an initial __update_entity_load_avg_contrib() update the first time we see the task. diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 1dff78a..9d1c193 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1557,8 +1557,8 @@ static void __sched_fork(struct task_struct *p) * load-balance). */ #if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED) - p->se.avg.runnable_avg_period = 0; - p->se.avg.runnable_avg_sum = 0; + p->se.avg.runnable_avg_period = 1024; + p->se.avg.runnable_avg_sum = 1024; #endif #ifdef CONFIG_SCHEDSTATS memset(>se.statistics, 0, sizeof(p->se.statistics)); > > > -- > Thanks > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 09/18] sched: add sched_policies in kernel
On 02/12/2013 06:36 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> Current scheduler behavior is just consider the for larger performance >> of system. So it try to spread tasks on more cpu sockets and cpu cores >> >> To adding the consideration of power awareness, the patchset adds >> 2 kinds of scheduler policy: powersaving and balance. They will use >> runnable load util in scheduler balancing. The current scheduling is taken >> as performance policy. >> >> performance: the current scheduling behaviour, try to spread tasks >> on more CPU sockets or cores. performance oriented. >> powersaving: will pack tasks into few sched group until all LCPU in the >> group is full, power oriented. >> balance: will pack tasks into few sched group until group_capacity >> numbers CPU is full, balance between performance and >> powersaving. > > _WHY_ do you start out with so much choice? > > If your power policy is so abysmally poor on performance that you > already know you need a 3rd policy to keep people happy, maybe you're > doing something wrong? Nope, no much performance yield for both of powersaving and balance policy. Much of testing results in replaying Ingo's email on '0/18' thread -- the cover letter email threads. https://lkml.org/lkml/2013/2/3/353 https://lkml.org/lkml/2013/2/4/735 I introduce a 'balance' policy just because HT thread LCPU in Intel CPU is less then 1 usual cpu power. It is used when someone want to save power but still want tasks have a whole cpu core... > >> +#define SCHED_POLICY_PERFORMANCE(0x1) >> +#define SCHED_POLICY_POWERSAVING(0x2) >> +#define SCHED_POLICY_BALANCE(0x4) >> + >> +extern int __read_mostly sched_policy; > > I'd much prefer: sched_balance_policy. Scheduler policy is a concept > already well defined by posix and we don't need it to mean two > completely different things. > Got it. -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] memcg: Add memory.pressure_level events
On Tue, Feb 12 2013, Anton Vorontsov wrote:
> Hi Greg,
>
> Thanks for taking a look!
>
> On Tue, Feb 12, 2013 at 10:42:51PM -0800, Greg Thelen wrote:
> [...]
>> > +static bool vmpressure_event(struct vmpressure *vmpr,
>> > + unsigned long s, unsigned long r)
>> > +{
>> > + struct vmpressure_event *ev;
>> > + int level = vmpressure_calc_level(vmpressure_win, s, r);
>> > + bool signalled = 0;
>> s/bool/int/
>
> Um... I surely can do this, but why do you think it is a good idea?
Because you incremented signalled below. Incrementing a bool seems
strange. A better fix would be to leave this a bool and
s/signaled++/signaled = true/ below.
>> > +
>> > + mutex_lock(>events_lock);
>> > +
>> > + list_for_each_entry(ev, >events, node) {
>> > + if (level >= ev->level) {
>> > + eventfd_signal(ev->efd, 1);
>> > + signalled++;
>> > + }
>> > + }
>> > +
>> > + mutex_unlock(>events_lock);
>> > +
>> > + return signalled;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kvm: Add MSR_AMD64_BU_CFG2 to the list of ignored MSRs
On Wed, Feb 13, 2013 at 12:42:41PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> The "x86, AMD: Enable WC+ memory type on family 10 processors" patch
> currently in -tip added a workaround for AMD F10h CPUs which #GPs my
> guest when booted in kvm. This is because it accesses MSR_AMD64_BU_CFG2
> which is not currently ignored by kvm. Do that because this MSR is only
> baremetal-relevant anyway. While at it, move the ignored MSRs at the
> beginning of kvm_set_msr_common so that we exit then and there.
>
> Signed-off-by: Borislav Petkov
> Cc: Boris Ostrovsky
> Cc: Andre Przywara
> Cc: Marcelo Tosatti
> Cc: Gleb Natapov
Acked-by: Gleb Natapov
Ingo, MSR_AMD64_BU_CFG2 exists only on tip. Can you get this through the
tip too?
> ---
> arch/x86/kvm/x86.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c243b81e3c74..37040079cd6b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1881,6 +1881,14 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> u64 data = msr_info->data;
>
> switch (msr) {
> + case MSR_AMD64_NB_CFG:
> + case MSR_IA32_UCODE_REV:
> + case MSR_IA32_UCODE_WRITE:
> + case MSR_VM_HSAVE_PA:
> + case MSR_AMD64_PATCH_LOADER:
> + case MSR_AMD64_BU_CFG2:
> + break;
> +
> case MSR_EFER:
> return set_efer(vcpu, data);
> case MSR_K7_HWCR:
> @@ -1900,8 +1908,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> return 1;
> }
> break;
> - case MSR_AMD64_NB_CFG:
> - break;
> case MSR_IA32_DEBUGCTLMSR:
> if (!data) {
> /* We support the non-activated case already */
> @@ -1914,11 +1920,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> vcpu_unimpl(vcpu, "%s: MSR_IA32_DEBUGCTLMSR 0x%llx, nop\n",
> __func__, data);
> break;
> - case MSR_IA32_UCODE_REV:
> - case MSR_IA32_UCODE_WRITE:
> - case MSR_VM_HSAVE_PA:
> - case MSR_AMD64_PATCH_LOADER:
> - break;
> case 0x200 ... 0x2ff:
> return set_msr_mtrr(vcpu, msr, data);
> case MSR_IA32_APICBASE:
> @@ -2253,6 +2254,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr,
> u64 *pdata)
> case MSR_K8_INT_PENDING_MSG:
> case MSR_AMD64_NB_CFG:
> case MSR_FAM10H_MMIO_CONF_BASE:
> + case MSR_AMD64_BU_CFG2:
> data = 0;
> break;
> case MSR_P6_PERFCTR0:
> --
> 1.8.1.3.535.ga923c31
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next v2] lockd: nlmclnt_reclaim(): avoid stack overflow
Even though nlmclnt_reclaim() is only one call into the stack frame,
928 bytes on the stack seems like a lot. Recode to dynamically
allocate the request structure once from within the reclaimer task,
then pass this pointer into nlmclnt_reclaim() for reuse on
subsequent calls.
smatch analysis:
fs/lockd/clntproc.c:620 nlmclnt_reclaim() warn: 'reqst' puts
928 bytes on stack
Also remove redundant assignment of 0 after memset.
Cc: Trond Myklebust
Cc: "J. Bruce Fields"
Cc: linux-...@vger.kernel.org
Signed-off-by: Tim Gardner
---
Changes from v1 -- don't return -ENOMEM from a task thread because it is
not propagated to the task creator. Instead print an error message and return.
fs/lockd/clntlock.c | 12 +++-
fs/lockd/clntproc.c |6 ++
include/linux/lockd/lockd.h |3 ++-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/lockd/clntlock.c b/fs/lockd/clntlock.c
index 4885b53..6cd673d 100644
--- a/fs/lockd/clntlock.c
+++ b/fs/lockd/clntlock.c
@@ -220,10 +220,19 @@ reclaimer(void *ptr)
{
struct nlm_host *host = (struct nlm_host *) ptr;
struct nlm_wait *block;
+ struct nlm_rqst *req;
struct file_lock *fl, *next;
u32 nsmstate;
struct net *net = host->net;
+ req = kmalloc(sizeof(*req), GFP_KERNEL);
+ if (!req) {
+ printk(KERN_ERR "lockd: reclaimer unable to alloc memory."
+ " Locks for %s won't be reclaimed!\n",
+ host->h_name);
+ return 0;
+ }
+
allow_signal(SIGKILL);
down_write(>h_rwsem);
@@ -253,7 +262,7 @@ restart:
*/
if (signalled())
continue;
- if (nlmclnt_reclaim(host, fl) != 0)
+ if (nlmclnt_reclaim(host, fl, req) != 0)
continue;
list_add_tail(>fl_u.nfs_fl.list, >h_granted);
if (host->h_nsmstate != nsmstate) {
@@ -279,5 +288,6 @@ restart:
/* Release host handle after use */
nlmclnt_release_host(host);
lockd_down(net);
+ kfree(req);
return 0;
}
diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
index 54f9e6c..b43114c 100644
--- a/fs/lockd/clntproc.c
+++ b/fs/lockd/clntproc.c
@@ -615,17 +615,15 @@ out_unlock:
* RECLAIM: Try to reclaim a lock
*/
int
-nlmclnt_reclaim(struct nlm_host *host, struct file_lock *fl)
+nlmclnt_reclaim(struct nlm_host *host, struct file_lock *fl,
+ struct nlm_rqst *req)
{
- struct nlm_rqst reqst, *req;
int status;
- req =
memset(req, 0, sizeof(*req));
locks_init_lock(>a_args.lock.fl);
locks_init_lock(>a_res.lock.fl);
req->a_host = host;
- req->a_flags = 0;
/* Set up the argument struct */
nlmclnt_setlockargs(req, fl);
diff --git a/include/linux/lockd/lockd.h b/include/linux/lockd/lockd.h
index f5a051a..a395f1e 100644
--- a/include/linux/lockd/lockd.h
+++ b/include/linux/lockd/lockd.h
@@ -212,7 +212,8 @@ int nlmclnt_block(struct nlm_wait *block, struct
nlm_rqst *req, long timeout)
__be32 nlmclnt_grant(const struct sockaddr *addr,
const struct nlm_lock *lock);
void nlmclnt_recovery(struct nlm_host *);
-int nlmclnt_reclaim(struct nlm_host *, struct file_lock *);
+int nlmclnt_reclaim(struct nlm_host *, struct file_lock *,
+ struct nlm_rqst *);
void nlmclnt_next_cookie(struct nlm_cookie *);
/*
--
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 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 05:29:43PM +0200, Kasatkin, Dmitry wrote: > On Wed, Feb 13, 2013 at 5:26 PM, Kasatkin, Dmitry > wrote: > > On Wed, Feb 13, 2013 at 4:38 PM, Vivek Goyal wrote: > >> On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote: > >>> It should not be the only line in the policy. > >>> Can you share full policy? > >> > >> I verified by putting some printk. There is only single rule in > >> ima_policy_rules list after I have updated the rules through "policy" > >> file. > >> > >> echo "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional" > > >> /sys/kernel/security/policy > > > > There is a default policy which has several rules. > > > > And when you do your "echo" you will replace all rules with that single > > rule. > > But ok, you have one rule only and it is fine to have even a single rule... > > > > What I have not said yet it is that in your case, because you use only > BPRM_CHECK hook, > you do not need "dont_appraise" and "dont_measure" rules for pseudo > filesystems. Agreed. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kvm: Add MSR_AMD64_BU_CFG2 to the list of ignored MSRs
On Wed, Feb 13, 2013 at 02:35:49PM +0100, Borislav Petkov wrote: > On Wed, Feb 13, 2013 at 02:10:02PM +0200, Gleb Natapov wrote: > > > > Is your guest compiled without PV support? With PV Linux traps #GP for > > > > all MSRs and it saves us in more than one places. > > > > > > Yes, CONFIG_PARAVIRT_GUEST is not set on the guest kernel. > > > > > Thanks. It does not mean that the patch should not be applied though. > > Right, > > but, come to think of it, adding an MSR each time to those functions > could turn out to be a PITA. The PV solution with trapping on the MSR > accesses might be better so maybe CONFIG_KVM should do > PV solution does not exists for some other guests. > select KVM_GUEST > > ? I can easily imaging the situation where one whats to build different kernels for host and guest and do not have PV in the host one. > > This is even a good forward-looking solution. > > > I cannot seems to find the documentation for the MSR anywhere, do you > > have a pointer? > > http://support.amd.com/us/Processor_TechDocs/31116.pdf, p.438 > Thanks, -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] leds-ot200: Fix misbehavior caused by wrong bit masks
During the development of this driver an in-house register
documentation was used. The last weeks some integration tests
were done and this problem was found. It turned out that
the released register documentation is wrong.
The fix is very simple: shift all masks by one.
Our customers can control LEDs from userspace via Java,
C++ or what every. They have running/working applications where
they want to control led_3 but led_2 get's used.
I got a bug report in our in-house bug tracker so it would be
great to fix this upstream.
Signed-off-by: Christian Gmeiner
---
drivers/leds/leds-ot200.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-ot200.c b/drivers/leds/leds-ot200.c
index ee14662..98cae52 100644
--- a/drivers/leds/leds-ot200.c
+++ b/drivers/leds/leds-ot200.c
@@ -47,37 +47,37 @@ static struct ot200_led leds[] = {
{
.name = "led_1",
.port = 0x49,
- .mask = BIT(7),
+ .mask = BIT(6),
},
{
.name = "led_2",
.port = 0x49,
- .mask = BIT(6),
+ .mask = BIT(5),
},
{
.name = "led_3",
.port = 0x49,
- .mask = BIT(5),
+ .mask = BIT(4),
},
{
.name = "led_4",
.port = 0x49,
- .mask = BIT(4),
+ .mask = BIT(3),
},
{
.name = "led_5",
.port = 0x49,
- .mask = BIT(3),
+ .mask = BIT(2),
},
{
.name = "led_6",
.port = 0x49,
- .mask = BIT(2),
+ .mask = BIT(1),
},
{
.name = "led_7",
.port = 0x49,
- .mask = BIT(1),
+ .mask = BIT(0),
}
};
--
1.7.12.2.421.g261b511
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542)
On 13-02-13 03:32 AM, Paolo Bonzini wrote: Il 06/02/2013 16:15, Paolo Bonzini ha scritto: This series regards the whitelist that is used for the SG_IO ioctl. This whitelist has three problems: * the bitmap of allowed commands is designed for MMC devices (roughly, "play/burn CDs without requiring root") but some opcodes overlap across SCSI device classes and have different meanings for different classes. * also because the bitmap of allowed commands is designed for MMC devices only, some commands are missing even though they are generally useful and not insecure. At least not more insecure than anything else you can do if you have access to /dev/sdX or /dev/stX nodes. * the whitelist can be disabled per-process but not per-disk. In addition, the required capability (CAP_SYS_RAWIO) gives access to a range of other resources, enough to make it insecure. The series corrects these problems. Patches 1-4 solve the first problem, which also has an assigned CVE, by using different bitmaps for the various device classes. Patches 5-11 solve the second by adding more commands to the bitmaps. Patches 12 and 13 solve the third, and were already posted but ignored by the maintainers despite multiple pings. Note: checkpatch hates the formatting of the command table. I know about this, and ensured that there are no errors in the rest of the code. The current formatting is IMHO quite handy, and roughly based on the files available from the SCSI standard body. Ok for the next merge window? Paolo v1->v2: remove 2 MMC commands and 6 SBC commands (see patches 6 and 9 for details). Added patch 14 and added a few more scanner commands based on SANE (scanners are not whitelisted by default, also were not in v1, but this makes it possible to opt into the whitelist out of paranoia). Removed C++ comments. Removed the large #if 0'd list of commands that the kernel does not pass though. Marked blk_set_cmd_filter_defaults as __init. Paolo Bonzini (14): sg_io: pass request_queue to blk_verify_command sg_io: reorganize list of allowed commands sg_io: use different default filters for each device class sg_io: resolve conflicts between commands assigned to multiple classes (CVE-2012-4542) sg_io: whitelist a few more commands for rare & obsolete device types sg_io: whitelist another command for multimedia devices sg_io: whitelist a few more commands for media changers sg_io: whitelist a few more commands for tapes sg_io: whitelist a few more commands for disks sg_io: whitelist a few obsolete commands sg_io: mark blk_set_cmd_filter_defaults as __init sg_io: remove remnants of sysfs SG_IO filters sg_io: introduce unpriv_sgio queue flag sg_io: use unpriv_sgio to disable whitelisting for scanners Documentation/block/queue-sysfs.txt |8 + block/blk-sysfs.c | 33 +++ block/bsg.c |2 +- block/scsi_ioctl.c | 369 ++- drivers/scsi/scsi_scan.c| 14 ++- drivers/scsi/sg.c |6 +- include/linux/blkdev.h |8 +- include/linux/genhd.h |9 - include/scsi/scsi.h |3 + 9 files changed, 344 insertions(+), 108 deletions(-) Ping? I'm not even sure what tree this should host these patches... You are whitelisting SCSI commands so obviously the SCSI tree and the patch spills over into the block tree. Can't see much point in ack-ing the sg changes since most of the action is at higher levels. The question I have is what existing code will this change break (and will I being getting emails from peeved developers)? Is 8 lines of documentation changes enough? My guess is that SG_IO ioctl pass-through users will be tripped up and it won't be obvious to them to look at Documentation/block/queue-sysfs.txt for enlightenment; especially if they are using a char device node from the bsg, sg or st drivers to issue SG_IO. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
> 3.7-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Dave Chinner
>
> commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.
>
> When _xfs_buf_find is passed an out of range address, it will fail
> to find a relevant struct xfs_perag and oops with a null
> dereference. This can happen when trying to walk a filesystem with a
> metadata inode that has a partially corrupted extent map (i.e. the
> block number returned is corrupt, but is otherwise intact) and we
> try to read from the corrupted block address.
>
> In this case, just fail the lookup. If it is readahead being issued,
> it will simply not be done, but if it is real read that fails we
> will get an error being reported. Ideally this case should result
> in an EFSCORRUPTED error being reported, but we cannot return an
> error through xfs_buf_read() or xfs_buf_get() so this lookup failure
> may result in ENOMEM or EIO errors being reported instead.
It looks like this breaks xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.
Paolo
> Signed-off-by: Dave Chinner
> Reviewed-by: Brian Foster
> Reviewed-by: Ben Myers
> Signed-off-by: Ben Myers
> Cc: CAI Qian
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> fs/xfs/xfs_buf.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -487,6 +487,7 @@ _xfs_buf_find(
> struct rb_node *parent;
> xfs_buf_t *bp;
> xfs_daddr_t blkno = map[0].bm_bn;
> + xfs_daddr_t eofs;
> int numblks = 0;
> int i;
>
> @@ -498,6 +499,23 @@ _xfs_buf_find(
> ASSERT(!(numbytes < (1 << btp->bt_sshift)));
> ASSERT(!(BBTOB(blkno) & (xfs_off_t)btp->bt_smask));
>
> + /*
> + * Corrupted block numbers can get through to here, unfortunately, so we
> + * have to check that the buffer falls within the filesystem bounds.
> + */
> + eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks);
> + if (blkno >= eofs) {
> + /*
> + * XXX (dgc): we should really be returning EFSCORRUPTED here,
> + * but none of the higher level infrastructure supports
> + * returning a specific error on buffer lookup failures.
> + */
> + xfs_alert(btp->bt_mount,
> + "%s: Block out of range: block 0x%llx, EOFS 0x%llx ",
> + __func__, blkno, eofs);
> + return NULL;
> + }
> +
> /* get tree root */
> pag = xfs_perag_get(btp->bt_mount,
> xfs_daddr_to_agno(btp->bt_mount, blkno));
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 5:26 PM, Kasatkin, Dmitry wrote: > On Wed, Feb 13, 2013 at 4:38 PM, Vivek Goyal wrote: >> On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote: >>> It should not be the only line in the policy. >>> Can you share full policy? >> >> I verified by putting some printk. There is only single rule in >> ima_policy_rules list after I have updated the rules through "policy" >> file. >> >> echo "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional" > >> /sys/kernel/security/policy > > There is a default policy which has several rules. > > And when you do your "echo" you will replace all rules with that single rule. > But ok, you have one rule only and it is fine to have even a single rule... > What I have not said yet it is that in your case, because you use only BPRM_CHECK hook, you do not need "dont_appraise" and "dont_measure" rules for pseudo filesystems. >> >> Thanks >> Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: fix wrong rq's runnable_avg update with rt task
On Wed, Feb 13, 2013 at 12:54 AM, Vincent Guittot
wrote:
> When a RT task is scheduled on an idle CPU, the update of the rq's load is
> not done because CFS's functions are not called. Then, the idle_balance,
> which is called just before entering the idle function, updates the
> rq's load and makes the assumption that the elapsed time since the last
> update, was only running time.
So an interesting point here is we intrinsically treat RT time
differently in our discount of the CPU power. It doesn't affect
anything in this patch per-say; but it should be kept in mind for
consistency when you do anything with the rq based numbers.
>
> The rq's load of a CPU that only runs a periodic RT task, is close to
> LOAD_AVG_MAX whatever the running duration of the RT task is.
>
> A new idle_exit function is called when the prev task is the idle function
> so the elapsed time will be accounted as idle time in the rq's load.
>
> Changes since V2:
> - remove useless definition for UP platform
> - rebased on top of Steven Rostedt's patches :
> https://lkml.org/lkml/2013/2/12/558
>
> Changes since V1:
> - move code out of schedule function and create a pre_schedule callback for
> idle class instead.
>
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/fair.c | 10 ++
> kernel/sched/idle_task.c |7 +++
> kernel/sched/sched.h |1 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0fcdbff..6af5db3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1562,6 +1562,16 @@ static inline void dequeue_entity_load_avg(struct
> cfs_rq *cfs_rq,
> se->avg.decay_count = atomic64_read(_rq->decay_counter);
> } /* migrations, e.g. sleep=0 leave decay_count == 0 */
> }
> +
> +/*
> + * Update the rq's load with the elapsed idle time before a task is
> + * scheduled. if the newly scheduled task is not a CFS task, idle_exit will
> + * be the only way to update the runnable statistic.
> + */
> +void idle_exit(int this_cpu, struct rq *this_rq)
> +{
> + update_rq_runnable_avg(this_rq, 0);
> +}
This does creates a somewhat sneaky dependency CONFIG_FAIR_GROUP_SCHED
bits and sched-idle; and it kind of hides the problem by making the
subsequent update a nop.
Is the root of the problem perhaps that we assume we were previously
runnable in idle_balance in the first place? Hmmm; this should
actually be essentially torn down by the dequeue of the last task in
the first place. I'd have to think about it carefully but arguably we
might be able to just remove the update_rq_runnable_avg from
idle_balance entirely.
We'd still need to make sure we pushed updates against rq->avg to
cover RT task time (something you correctly point out is currently not
accounted, and which entry/exit from idle-task seems a reasonable
place); but this can then be independent of all the cgroup specific
bits.
> #else
> static inline void update_entity_load_avg(struct sched_entity *se,
> int update_cfs_rq) {}
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 66b5220..6e7e63c 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -14,6 +14,12 @@ select_task_rq_idle(struct task_struct *p, int sd_flag,
> int flags)
> return task_cpu(p); /* IDLE tasks as never migrated */
> }
>
> +static void pre_schedule_idle(struct rq *rq, struct task_struct *prev)
> +{
> + /* Update rq's load with elapsed idle time */
> + idle_exit(smp_processor_id(), rq);
> +}
> +
> static void post_schedule_idle(struct rq *rq)
> {
> idle_balance(smp_processor_id(), rq);
> @@ -95,6 +101,7 @@ const struct sched_class idle_sched_class = {
>
> #ifdef CONFIG_SMP
> .select_task_rq = select_task_rq_idle,
> + .pre_schedule = pre_schedule_idle,
> .post_schedule = post_schedule_idle,
> #endif
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index fc88644..5f26c93f 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -877,6 +877,7 @@ extern const struct sched_class idle_sched_class;
>
> extern void trigger_load_balance(struct rq *rq, int cpu);
> extern void idle_balance(int this_cpu, struct rq *this_rq);
> +extern void idle_exit(int this_cpu, struct rq *this_rq);
>
> #else /* CONFIG_SMP */
>
> --
> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] virt_mmio: fix signature checking for BE guests
On 13/02/13 15:08, Pawel Moll wrote: > On Wed, 2013-02-13 at 14:25 +, Marc Zyngier wrote: >> Using readl() to read the magic value and then memcmp() to check it >> fails on BE, as bytes will be the other way around (by virtue of >> the registers to follow the endianess of the guest). > > Hm. Interesting. I missed the fact that readl() as a "PCI operation" > will always assume LE values... > >> Fix it by encoding the magic as an integer instead of a string. >> So I'm not completely sure this is the right fix, > > It seems right, however... > >> - Using __raw_readl() instead. Is that a generic enough API? >> > ... this implies that either the spec is wrong (as it should say: the > device registers are always LE, in the PCI spirit) or all readl()s & co. > should be replaced with __raw equivalents. Well, the spec clearly says that the registers reflect the endianess of the guest, and it makes sense: when performing the MMIO access, KVM needs to convert between host and guest endianess. > Having said that, does the change make everything else work with a BE > guest? (I assume we're talking about the guest being BE, right? ;-) If > so it means that the host is not following the current spec and it > treats all the registers as LE. Yes, I only care about a BE guest. And no, not much is actually working (kvmtool is not happy about the guest addresses it finds in the virtio-ring). Need to dive into it and understand what needs to be fixed... >> - Reading the MAGIC register byte by byte. Is that allowed? The spec >> only says it is 32bit wide. > > And the spirit of the spec was: _exactly 32bit wide_. It's just simpler > to implement one access width on the host side. I guessed as much... M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 4:38 PM, Vivek Goyal wrote: > On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote: >> It should not be the only line in the policy. >> Can you share full policy? > > I verified by putting some printk. There is only single rule in > ima_policy_rules list after I have updated the rules through "policy" > file. > > echo "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional" > > /sys/kernel/security/policy There is a default policy which has several rules. And when you do your "echo" you will replace all rules with that single rule. But ok, you have one rule only and it is fine to have even a single rule... > > Thanks > Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 08/18] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking"
On 02/12/2013 06:27 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then >> we can use runnable load variables. >> > It would be nice if we could quantify the performance hit of doing so. > Haven't yet looked at later patches to see if we remove anything to > off-set this. > In our rough testing, no much clear performance changes. -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: BUG at net/sunrpc/svc_xprt.c:921 (another one)
On 13-02-12 03:52 PM, J. Bruce Fields wrote: > On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote: >> Got it again, this time on a different system >> running mostly the same software. > > Mark, Paweł, Tom, could any of you confirm whether this helps? .. No, I cannot confirm one way or the other, because I haven't noticed it again since the most recent couple of occurrences I posted earlier here. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Enhanced support for MPC8xx/8xxx watchdog
This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second. This is not in line with the Linux watchdog concept
which is based on a default watchdog timeout around 60s.
This patch introduces an intermediate layer between the CPU and the userspace.
The kernel pings the watchdog at the required frequency at the condition that
userspace tools refresh it regularly.
The new parameter 'heartbeat' allows to set up the userspace timeout.
The driver also implements the WDIOC_SETTIMEOUT ioctl.
Signed-off-by: Christophe Leroy
diff -ur linux-3.7.7/drivers/watchdog/mpc8xxx_wdt.c
linux/drivers/watchdog/mpc8xxx_wdt.c
--- linux-3.7.7/drivers/watchdog/mpc8xxx_wdt.c 2013-02-11 18:05:09.0
+0100
+++ linux/drivers/watchdog/mpc8xxx_wdt.c2013-02-13 15:55:22.0
+0100
@@ -52,10 +52,17 @@
static struct mpc8xxx_wdt __iomem *wd_base;
static int mpc8xxx_wdt_init_late(void);
+#define WD_TIMO 10 /* Default heartbeat = 10 seconds */
+
+static int heartbeat = WD_TIMO;
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat,
+ "Watchdog SW heartbeat in seconds. (0 < heartbeat < 65536s, default="
+ __MODULE_STRING(WD_TIMO) "s)");
static u16 timeout = 0x;
module_param(timeout, ushort, 0);
MODULE_PARM_DESC(timeout,
- "Watchdog timeout in ticks. (0swcrr, tmp);
- del_timer_sync(_timer);
+ wdt_auto = 0;
return nonseekable_open(inode, file);
}
@@ -138,7 +158,8 @@
static int mpc8xxx_wdt_release(struct inode *inode, struct file *file)
{
if (!nowayout)
- mpc8xxx_wdt_timer_ping(0);
+ wdt_auto = 1;
+
else
mpc8xxx_wdt_pr_warn("watchdog closed");
clear_bit(0, _is_open);
@@ -163,10 +184,12 @@
case WDIOC_GETBOOTSTATUS:
return put_user(0, p);
case WDIOC_KEEPALIVE:
- mpc8xxx_wdt_keepalive();
+ mpc8xxx_wdt_sw_keepalive();
return 0;
case WDIOC_GETTIMEOUT:
- return put_user(timeout_sec, p);
+ return put_user(heartbeat, p);
+ case WDIOC_SETTIMEOUT:
+ return get_user(heartbeat, p);
default:
return -ENOTTY;
}
@@ -215,6 +238,8 @@
ret = -ENOSYS;
goto err_unmap;
}
+ if (enabled)
+ timeout = in_be32(_base->swcrr) >> 16;
/* Calculate the timeout in seconds */
if (prescale)
@@ -273,6 +298,7 @@
.compatible = "fsl,mpc823-wdt",
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x800,
+ .hw_enabled = true,
},
},
{},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scheduler include file reorganization
On Wed, 13 Feb 2013 10:15:12 +0100 Ingo Molnar wrote: > > * Namhyung Kim wrote: > > > Hi, > > > > On Mon, 11 Feb 2013 10:54:58 +0100, Ingo Molnar wrote: > > > * Clark Williams wrote: > > > > > >> I figured that was coming. :) > > > > > > ;-) > > > > > >> I'll look at it again and see about pulling the > > >> autogroup/cgroup stuff into it's own header. After that it's > > >> probably going to require some serious changes. > > >> > > >> Any suggestions? > > > > > > I'd suggest doing it as finegrained as possible - potentially > > > one concept at a time. I wouldn't mind a dozen small files in > > > include/linux/sched/ - possibly more. > > > > What about the .c files? AFAICS the sched/core.c and > > sched/fair.c are rather huge and contain various concepts > > which might be separated to their own files. It'd be better > > reorganizing them too IMHO. > > I'd be more careful about those, because there's various > scheduler patch-sets floating modifying them. > > sched.h is much more static and it is the one that actually gets > included in like 60% of all *other* .c files, adding a few > thousand lines to every .o compilation and causing measurable > compile time overhead ... > > So sched.h splitting is something we should really do, if > there's people interested in and capable of pulling it off. > > Thanks, > > Ingo And since I'm one of the people that care about the RT patch (which modifies the scheduler files) I'll just start with baby steps and reorg the headers. Clark signature.asc Description: PGP signature
[PATCH] ptrace: add ability to retrieve signals without removing them from a queue
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about a signal with the
specified sequence number. A siginfo_t structure is copied from the child
to location data in the parent.
The low 16 bits of addr contains a sequence number of signal in a queue.
All other bits of addr is used for flags. Currently here is only one
flag PTRACE_PEEK_SHARED for dumping signals from process-wide shared
queue. If this flag is not set, a signal is read from a per-thread
queue. A result siginfo contains a kernel part of si_code which usually
striped, but it's required for queuing the same siginfo back during
restore of pending signals.
If a signal with the specified sequence number doesn't exist, ptrace
returns ENOENT.
This functionality is required for checkpointing pending signals.
The prototype of this code was developed by Oleg Nesterov.
Cc: Roland McGrath
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: "Paul E. McKenney"
Cc: David Howells
Cc: Dave Jones
Cc: "Michael Kerrisk (man-pages)"
Cc: Pavel Emelyanov
Cc: Linus Torvalds
Signed-off-by: Andrey Vagin
---
include/uapi/linux/ptrace.h | 9 +++
kernel/ptrace.c | 64 +
2 files changed, 73 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index 022ab18..5d851d5 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -52,6 +52,15 @@
#define PTRACE_INTERRUPT 0x4207
#define PTRACE_LISTEN 0x4208
+#define PTRACE_PEEKSIGINFO 0x4209
+
+/*
+ * The lower 16 bits of addr is a sequence number of a signal.
+ * All other bits can be used for flags.
+ */
+#define PTRACE_PEEKSIGINFO_FLAGS_MASK (~0UL << 16)
+#define PTRACE_PEEK_SHARED (1UL << 31)
+
/* Wait extended result codes for the above trace options. */
#define PTRACE_EVENT_FORK 1
#define PTRACE_EVENT_VFORK 2
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 1599157..27fd31a 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -579,6 +579,40 @@ static int ptrace_setsiginfo(struct task_struct *child,
const siginfo_t *info)
return error;
}
+#ifdef CONFIG_CHECKPOINT_RESTORE
+static int ptrace_peek_siginfo(struct task_struct *child,
+ unsigned long addr, siginfo_t *siginfo)
+{
+ struct sigpending *pending;
+ struct sigqueue *q;
+ unsigned long flags;
+ unsigned int nr;
+ int ret = -ENOENT;
+
+ nr = addr & ~PTRACE_PEEKSIGINFO_FLAGS_MASK;
+ flags = addr & PTRACE_PEEKSIGINFO_FLAGS_MASK;
+
+ if (flags & PTRACE_PEEK_SHARED)
+ pending = >signal->shared_pending;
+ else
+ pending = >pending;
+
+ if (flags & ~PTRACE_PEEK_SHARED)
+ return -EINVAL; /* unknown flags */
+
+ spin_lock_irq(>sighand->siglock);
+ list_for_each_entry(q, >list, list) {
+ if (!nr--) {
+ copy_siginfo(siginfo, >info);
+ ret = 0;
+ break;
+ }
+ }
+ spin_unlock_irq(>sighand->siglock);
+
+ return ret;
+}
+#endif
#ifdef PTRACE_SINGLESTEP
#define is_singlestep(request) ((request) == PTRACE_SINGLESTEP)
@@ -703,6 +737,21 @@ int ptrace_request(struct task_struct *child, long request,
ret = put_user(child->ptrace_message, datalp);
break;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ case PTRACE_PEEKSIGINFO:
+ {
+ siginfo_t __user *uinfo = (siginfo_t __user *) data;
+
+ ret = ptrace_peek_siginfo(child, addr, );
+
+ if (!ret)
+ ret = copy_siginfo_to_user(uinfo, );
+ if (!ret)
+ ret = __put_user(siginfo.si_code, >si_code);
+ break;
+ }
+#endif
+
case PTRACE_GETSIGINFO:
ret = ptrace_getsiginfo(child, );
if (!ret)
@@ -959,6 +1008,21 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
ret = put_user((compat_ulong_t) child->ptrace_message, datap);
break;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ case PTRACE_PEEKSIGINFO:
+ {
+ compat_siginfo_t __user *uinfo = compat_ptr(data);
+
+ ret = ptrace_peek_siginfo(child, addr, );
+
+ if (!ret)
+ ret = copy_siginfo_to_user32(uinfo, );
+ if (!ret)
+ ret = __put_user(siginfo.si_code, >si_code);
+ break;
+ }
+#endif
+
case PTRACE_GETSIGINFO:
ret = ptrace_getsiginfo(child, );
if (!ret)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [patch v4 07/18] sched: set initial load avg of new forked task
On 02/12/2013 06:26 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> + /* >> +* set the initial load avg of new task same as its load >> +* in order to avoid brust fork make few cpu too heavier >> +*/ >> + if (flags & ENQUEUE_NEWTASK) >> + se->avg.load_avg_contrib = se->load.weight; > > I seem to have vague recollections of a discussion with pjt where we > talk about the initial behaviour of tasks; from this haze I had the > impression that new tasks should behave like full weight.. > Here just make the new task has full weight.. > PJT is something more fundamental screwy? > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] lib/scatterlist: use page iterator in the mapping iterator
For better code reuse use the newly added page iterator to iterate
through the pages. The offset, length within the page is still
calculated by the mapping iterator as well as the actual mapping.
Idea from Tejun Heo .
Signed-off-by: Imre Deak
---
include/linux/scatterlist.h |6 +++---
lib/scatterlist.c | 46 ---
2 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 788a853..a6cd692 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -295,9 +295,9 @@ struct sg_mapping_iter {
size_t consumed; /* number of consumed bytes */
/* these are internal states, keep away */
- struct scatterlist *__sg; /* current entry */
- unsigned int__nents;/* nr of remaining entries */
- unsigned int__offset; /* offset within sg */
+ unsigned int__offset; /* offset within page */
+ struct sg_page_iter __piter;/* page iterator */
+ unsigned int__remaining;/* remaining bytes on page */
unsigned int__flags;
};
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index a1d1564..4e4974a 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -449,9 +449,7 @@ void sg_miter_start(struct sg_mapping_iter *miter, struct
scatterlist *sgl,
{
memset(miter, 0, sizeof(struct sg_mapping_iter));
- miter->__sg = sgl;
- miter->__nents = nents;
- miter->__offset = 0;
+ __sg_page_iter_start(>__piter, sgl, nents, 0);
WARN_ON(!(flags & (SG_MITER_TO_SG | SG_MITER_FROM_SG)));
miter->__flags = flags;
}
@@ -476,36 +474,33 @@ EXPORT_SYMBOL(sg_miter_start);
*/
bool sg_miter_next(struct sg_mapping_iter *miter)
{
- unsigned int off, len;
-
- /* check for end and drop resources from the last iteration */
- if (!miter->__nents)
- return false;
-
sg_miter_stop(miter);
- /* get to the next sg if necessary. __offset is adjusted by stop */
- while (miter->__offset == miter->__sg->length) {
- if (--miter->__nents) {
- miter->__sg = sg_next(miter->__sg);
- miter->__offset = 0;
- } else
+ /*
+* Get to the next page if necessary.
+* __remaining, __offset is adjusted by sg_miter_stop
+*/
+ if (!miter->__remaining) {
+ struct scatterlist *sg;
+ unsigned long pgoffset;
+
+ if (!__sg_page_iter_next(>__piter))
return false;
- }
- /* map the next page */
- off = miter->__sg->offset + miter->__offset;
- len = miter->__sg->length - miter->__offset;
+ sg = miter->__piter.sg;
+ pgoffset = miter->__piter.sg_pgoffset;
- miter->page = nth_page(sg_page(miter->__sg), off >> PAGE_SHIFT);
- off &= ~PAGE_MASK;
- miter->length = min_t(unsigned int, len, PAGE_SIZE - off);
- miter->consumed = miter->length;
+ miter->__offset = pgoffset ? 0 : sg->offset;
+ miter->__remaining = sg->offset + sg->length -
+ (pgoffset << PAGE_SHIFT) - miter->__offset;
+ }
+ miter->page = miter->__piter.page;
+ miter->consumed = miter->length = miter->__remaining;
if (miter->__flags & SG_MITER_ATOMIC)
- miter->addr = kmap_atomic(miter->page) + off;
+ miter->addr = kmap_atomic(miter->page) + miter->__offset;
else
- miter->addr = kmap(miter->page) + off;
+ miter->addr = kmap(miter->page) + miter->__offset;
return true;
}
@@ -532,6 +527,7 @@ void sg_miter_stop(struct sg_mapping_iter *miter)
/* drop resources from the last iteration */
if (miter->addr) {
miter->__offset += miter->consumed;
+ miter->__remaining -= miter->consumed;
if (miter->__flags & SG_MITER_TO_SG)
flush_kernel_dcache_page(miter->page);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] lib/scatterlist: add simple page iterator
Add an iterator to walk through a scatter list a page at a time starting
at a specific page offset. As opposed to the mapping iterator this is
meant to be small, performing well even in simple loops like collecting
all pages on the scatterlist into an array or setting up an iommu table
based on the pages' DMA address.
v2:
- sg_pgoffset pointed incorrectly at the next page not the current one.
v3:
- formatting fixes, documentation (Andrew)
- uninline helper functions, as they are too big (Andrew)
- support for terminating the iteration after a maximum number
sglist->nents entries, needed by the next patch
Signed-off-by: Imre Deak
---
include/linux/scatterlist.h | 35 +++
lib/scatterlist.c | 38 ++
2 files changed, 73 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 4bd6c06..788a853 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -231,6 +231,41 @@ size_t sg_copy_to_buffer(struct scatterlist *sgl, unsigned
int nents,
*/
#define SG_MAX_SINGLE_ALLOC(PAGE_SIZE / sizeof(struct scatterlist))
+/*
+ * sg page iterator
+ *
+ * Iterates over sg entries page-by-page. On each successful iteration,
+ * @piter->page points to the current page, @piter->sg to the sg holding this
+ * page and @piter->sg_pgoffset to the page's page offset within the sg. The
+ * iteration will stop either when a maximum number of sg entries was reached
+ * or a terminating sg (sg_last(sg) == true) was reached.
+ */
+struct sg_page_iter {
+ struct page *page; /* current page */
+ struct scatterlist *sg;/* sg holding the page */
+ unsigned intsg_pgoffset;/* page offset within the sg */
+
+ /* these are internal states, keep away */
+ unsigned int__nents;/* remaining sg entries */
+ int __pg_advance; /* nr pages to advance at the
+* next step */
+};
+
+bool __sg_page_iter_next(struct sg_page_iter *piter);
+void __sg_page_iter_start(struct sg_page_iter *piter,
+ struct scatterlist *sglist, unsigned int nents,
+ unsigned long pgoffset);
+
+/**
+ * for_each_sg_page - iterate over the pages of the given sg list
+ * @sglist:sglist to iterate over
+ * @piter: page iterator to hold current page, sg, sg_pgoffset
+ * @nents: maximum number of sg entries to iterate over
+ * @pgoffset: starting page offset
+ */
+#define for_each_sg_page(sglist, piter, nents, pgoffset) \
+ for (__sg_page_iter_start((piter), (sglist), (nents), (pgoffset)); \
+__sg_page_iter_next(piter);)
/*
* Mapping sg iterator
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 7874b01..a1d1564 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -394,6 +394,44 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
}
EXPORT_SYMBOL(sg_alloc_table_from_pages);
+void __sg_page_iter_start(struct sg_page_iter *piter,
+ struct scatterlist *sglist, unsigned int nents,
+ unsigned long pgoffset)
+{
+ piter->__pg_advance = 0;
+ piter->__nents = nents;
+
+ piter->page = NULL;
+ piter->sg = sglist;
+ piter->sg_pgoffset = pgoffset;
+}
+EXPORT_SYMBOL(__sg_page_iter_start);
+
+static int sg_page_count(struct scatterlist *sg)
+{
+ return PAGE_ALIGN(sg->offset + sg->length) >> PAGE_SHIFT;
+}
+
+bool __sg_page_iter_next(struct sg_page_iter *piter)
+{
+ if (!piter->__nents || !piter->sg)
+ return false;
+
+ piter->sg_pgoffset += piter->__pg_advance;
+ piter->__pg_advance = 1;
+
+ while (piter->sg_pgoffset >= sg_page_count(piter->sg)) {
+ piter->sg_pgoffset -= sg_page_count(piter->sg);
+ piter->sg = sg_next(piter->sg);
+ if (!--piter->__nents || !piter->sg)
+ return false;
+ }
+ piter->page = nth_page(sg_page(piter->sg), piter->sg_pgoffset);
+
+ return true;
+}
+EXPORT_SYMBOL(__sg_page_iter_next);
+
/**
* sg_miter_start - start mapping iteration over a sg list
* @miter: sg mapping iter to be started
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] virt_mmio: fix signature checking for BE guests
On Wed, 2013-02-13 at 14:25 +, Marc Zyngier wrote: > Using readl() to read the magic value and then memcmp() to check it > fails on BE, as bytes will be the other way around (by virtue of > the registers to follow the endianess of the guest). Hm. Interesting. I missed the fact that readl() as a "PCI operation" will always assume LE values... > Fix it by encoding the magic as an integer instead of a string. > So I'm not completely sure this is the right fix, It seems right, however... > - Using __raw_readl() instead. Is that a generic enough API? > ... this implies that either the spec is wrong (as it should say: the device registers are always LE, in the PCI spirit) or all readl()s & co. should be replaced with __raw equivalents. Having said that, does the change make everything else work with a BE guest? (I assume we're talking about the guest being BE, right? ;-) If so it means that the host is not following the current spec and it treats all the registers as LE. > - Reading the MAGIC register byte by byte. Is that allowed? The spec > only says it is 32bit wide. And the spirit of the spec was: _exactly 32bit wide_. It's just simpler to implement one access width on the host side. Paweł -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 03/18] sched: fix find_idlest_group mess logical
On 02/12/2013 06:16 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> There is 4 situations in the function: >> 1, no task allowed group; >> so min_load = ULONG_MAX, this_load = 0, idlest = NULL >> 2, only local group task allowed; >> so min_load = ULONG_MAX, this_load assigned, idlest = NULL >> 3, only non-local task group allowed; >> so min_load assigned, this_load = 0, idlest != NULL >> 4, local group + another group are task allowed. >> so min_load assigned, this_load assigned, idlest != NULL >> >> Current logical will return NULL in first 3 kinds of scenarios. >> And still return NULL, if idlest group is heavier then the >> local group in the 4th situation. >> >> Actually, I thought groups in situation 2,3 are also eligible to host >> the task. And in 4th situation, agree to bias toward local group. > > I'm not convinced this is actually a cleanup.. taken together with patch > 4 (which is a direct consequence of this patch afaict) you replace one > conditional with 2. > The current logical will always miss the eligible CPU in the 3rd situation. 'sd = sd->child' still skip the non-local group eligible CPU. -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Congatec CGEB base, i2c and watchdog driver support
2013/2/12 Sascha Hauer : > I'd like to come back to this topic. I have sent patches last year > already, changes to the last time I posted this is mainly that > I moved the CGEB base support from drivers/mfd/ to arch/x86/platform/ > like suggested by Samuel Ortiz back then. > > The following series adds support for the Congatec CGEB interface > found on some Congatec x86 boards. The CGEB interface is a BIOS > interface which provides access to onboard peripherals like I2C > busses and watchdogs. It works by mapping BIOS code and searching > for magic values which specify the entry points to the CGEB call. > The CGEB call is an API provided by the BIOS which provides access > to the functions in an ioctl like fashion. > > For more information about the CGEB API have a look at: > > http://www.congatec.com/single_news+M5d58c9cd155.html > > This document only describes the C API, unfortunately not the > underlying BIOS interface. > > Also added are two users of this interface, a i2c master driver > and a watchdog driver. > > Comments very appreciated. Hi Sascha, against what version is this patch set? Would like to try it out but it fails to apply to 3.8-rc7. -- Christian Gmeiner, MSc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging/comedi: Fix undefined array subscript
Looks great. :) Thanks for fixing this bug. regards, dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/scatterlist: add simple page iterator
On Tue, 2013-02-12 at 09:13 -0800, Tejun Heo wrote:
> Hello,
>
> On Tue, Feb 12, 2013 at 07:07:20PM +0200, Imre Deak wrote:
> > It's the one implemented by sg_miter_{start,stop} in scatterlist.c. It
> > also iterates through a scatterlist a page at a time, but it also kmaps
> > these pages. Since in our use case we don't need to map the pages we
> > needed a solution without this overhead.
>
> I'm not against having non-mapping iterator but please consider that
> kmaps are no-ops on many configurations. It matters only for archs w/
> high memory.
Ok, I haven't thought about that. But in any case we care about those
archs too and would like to avoid the mapping there as well.
> > where each entry on the sglist contained 16 consecutive pages. This
> > takes ~10% more time for the uninlined version to run. This is a rather
> > artificial test and I couldn't come up with something more real-life
> > using only the i915 driver's ioctl interface that would show a
> > significant change in speed.
> >
> > So at least for now I'm ok with just uninlining all the helpers.
>
> Can we reimplement mapping iters using the new ones?
Yes I think it's a good idea, I will follow up with a new patchset
addressing this and Andrew's comments.
Thanks,
Imre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rwsem: Implement writer lock-stealing
* Alex Shi wrote: > On 02/09/2013 10:45 AM, Michel Lespinasse wrote: > > This proposal implements writer lock stealing in lib/rwsem.c, just as > > Alex Shi's earlier proposal did for the simpler lib/rwsem-spinlock.c > > Ops, my patch in tip/urgent is for rwsem. Yuanhan's patch is > for rwsem-spinlock. Your rwsem patch is queued up for v3.9, in the tip:core/locking tree: 3a15e0e0cdda rwsem: Implement writer lock-stealing for better scalability Michel, mind having a look at that and possibly generate a delta patch, if your patch has changes we should apply? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 02/18] sched: select_task_rq_fair clean up
On 02/12/2013 06:14 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> It is impossible to miss a task allowed cpu in a eligible group. > > I suppose your reasoning goes like: tsk->cpus_allowed is protected by > ->pi_lock, we hold this, therefore it cannot change and > find_idlest_group() dtrt? yes. > > We can then state that this is due to adding proper serialization to > tsk->cpus_allowed. > >> And since find_idlest_group only return a different group which >> excludes old cpu, it's also impossible to find a new cpu same as old >> cpu. > > Sounds plausible, but I'm not convinced, do we have hard serialization > against hotplug? Any caller of select_task_rq will check if returned dst_cpu is still working. So there is nothing need worry about. > > > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next] lockd: nlmsvc_mark_resources(): avoid stack overflow
On 02/12/2013 02:22 PM, J. Bruce Fields wrote:
> On Tue, Feb 12, 2013 at 12:48:58PM -0700, Tim Gardner wrote:
>> Dynamically allocate the NLM host structure in order to avoid stack overflow.
>> nlmsvc_mark_resources() is several call levels deep in a stack
>> that has a number of large variables. 512 bytes seems like a lot
>> on the stack at this point.
>>
>> smatch analysis:
>>
>> fs/lockd/svcsubs.c:366 nlmsvc_mark_resources() warn: 'hint' puts
>> 512 bytes on stack
>>
>> Cc: Trond Myklebust
>> Cc: "J. Bruce Fields"
>> Cc: linux-...@vger.kernel.org
>> Signed-off-by: Tim Gardner
>> ---
>> fs/lockd/svcsubs.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
>> index b904f41..f3abb7f 100644
>> --- a/fs/lockd/svcsubs.c
>> +++ b/fs/lockd/svcsubs.c
>> @@ -363,11 +363,15 @@ nlmsvc_is_client(void *data, struct nlm_host *dummy)
>> void
>> nlmsvc_mark_resources(struct net *net)
>> {
>> -struct nlm_host hint;
>> +struct nlm_host *hint = kzalloc(sizeof(*hint), GFP_KERNEL);
>>
>> -dprintk("lockd: nlmsvc_mark_resources for net %p\n", net);
>> -hint.net = net;
>> -nlm_traverse_files(, nlmsvc_mark_host, NULL);
>> +if (hint) {
>> +dprintk("lockd: nlmsvc_mark_resources for net %p\n", net);
>> +hint->net = net;
>> +nlm_traverse_files(hint, nlmsvc_mark_host, NULL);
>> +}
>
> Silently neglecting to do this looks like a bad idea.
>
> It's strange that we're passing in an nlm_host when all we actually use
> is the struct net*. Why not just change this to pass in the net
> instead?
>
> --b.
>
It won't really be silent. k[zm]alloc() dumps a stack trace on failure
to allocate unless GFP_NOWARN is set in the flags. I think this is a bit
better then possibly corrupting the stack.
Changing the prototype to just pass in 'net' has knock on effects that
make this patch a whole lot bigger. You'd have to change the code within
a bunch of functions which are difficult to verify at compile time
because of the use of 'void *data' as the first parameter. Is there
still a good reason for that parameter to be opaque ?
rtg
--
Tim Gardner tim.gard...@canonical.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote: > It should not be the only line in the policy. > Can you share full policy? I verified by putting some printk. There is only single rule in ima_policy_rules list after I have updated the rules through "policy" file. echo "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional" > /sys/kernel/security/policy Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SELinux + ubifs: possible circular locking dependency
On 02/13/2013 01:47 PM, Artem Bityutskiy wrote:
>> I'm on a arm imx28 v3.8-rc6 (+ a handfull of patches to support the
>> custom board) but no modifications on ubifs, selinux or the vfs layer.
>> And not including the xattr patches by Subodh Nijsure.
>>
>> When booting with SELinux and lockdep enabled I see this _possible_
>> circular locking dependency:
>
> I guess one needs to really understand how lockdep works, because it
> seems there is no direct 'tnc_mutex -> isec->lock', and lockdep somehow
> deducts this connection inderectly.
>
> However, it seems I see what _may_ be the reason, and here is a patch
> which I think may fix the issue. Would you please test/review it? It is
> inlined and also attached.
Thanks,
[...]
The compiler complains
security/selinux/hooks.c:210:2: error: incompatible type for argument 3 of
'lockdep_init_map'
In file included from include/linux/spinlock_types.h:18:0,
from include/linux/spinlock.h:81,
from include/linux/seqlock.h:29,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:17,
from include/linux/tracehook.h:49,
from security/selinux/hooks.c:29:
include/linux/lockdep.h:279:13: note: expected 'struct lock_class_key *' but
argument is of type 'struct lock_class_key'
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index ef26e96..328180e 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -207,6 +207,7 @@ static int inode_alloc_security(struct inode *inode)
> return -ENOMEM;
>
> mutex_init(>lock);
> + lockdep_set_class(>lock, inode->i_sb->s_type->i_mutex_key);
So I added an "&", so that the line looks like that:
+ lockdep_set_class(>lock, >i_sb->s_type->i_mutex_key);
> INIT_LIST_HEAD(>list);
> isec->inode = inode;
> isec->sid = SECINITSID_UNLABELED;
>
That solves original circular lock warning, but brings these two:
> [0.213843] [ cut here ]
> [0.218687] WARNING: at kernel/lockdep.c:702 __lock_acquire+0x1824/0x1c58()
> [0.225875] Modules linked in:
> [0.229156] [] (unwind_backtrace+0x0/0xf0) from []
> (warn_slowpath_common+0x4c/0x64)
> [0.238812] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_null+0x1c/0x24)
> [0.248750] [] (warn_slowpath_null+0x1c/0x24) from []
> (__lock_acquire+0x1824/0x1c58)
> [0.258500] [] (__lock_acquire+0x1824/0x1c58) from []
> (lock_acquire+0x88/0x9c)
> [0.267750] [] (lock_acquire+0x88/0x9c) from []
> (mutex_lock_nested+0x5c/0x2ec)
> [0.276968] [] (mutex_lock_nested+0x5c/0x2ec) from []
> (lock_mount+0x1c/0xbc)
> [0.286031] [] (lock_mount+0x1c/0xbc) from []
> (do_add_mount+0x18/0xc8)
> [0.294531] [] (do_add_mount+0x18/0xc8) from []
> (do_mount+0x1cc/0x8d0)
> [0.303062] [] (do_mount+0x1cc/0x8d0) from []
> (sys_mount+0x84/0xb8)
> [0.311343] [] (sys_mount+0x84/0xb8) from []
> (devtmpfsd+0x4c/0x2b8)
> [0.319593] [] (devtmpfsd+0x4c/0x2b8) from []
> (kthread+0xa4/0xb0)
> [0.327656] [] (kthread+0xa4/0xb0) from []
> (ret_from_fork+0x14/0x2c)
> [0.336062] ---[ end trace 1b75b31a2719ed1c ]---
The warning comes from:
list_for_each_entry(class, hash_head, hash_entry) {
if (class->key == key) {
/*
* Huh! same key, different name? Did someone trample
* on some memory? We're most confused.
*/
WARN_ON_ONCE(class->name != lock->name);
return class;
}
}
[...]
> [0.342000] devtmpfs: initialized
> [0.350187] pinctrl core: initialized pinctrl subsystem
> [0.358000]
> [0.359656] =
> [0.365218] [ INFO: possible recursive locking detected ]
> [0.370812] 3.8.0-rc7-00011-g7a589e1-dirty #108 Tainted: GW
> [0.377562] -
> [0.383125] swapper/1 is trying to acquire lock:
> [0.387906] (>i_sb->s_type->i_mutex_key#7){+.+.+.}, at:
> [] inode_doinit_with_dentry+0x8c/0x55c
> [0.398437]
> [0.398437] but task is already holding lock:
> [0.404562] (>i_sb->s_type->i_mutex_key#7){+.+.+.}, at:
> [] __create_file+0x50/0x25c
> [0.414093]
> [0.414093] other info that might help us debug this:
> [0.420906] Possible unsafe locking scenario:
> [0.420906]
> [0.427125]CPU0
> [0.429687]
> [0.432250] lock(>i_sb->s_type->i_mutex_key#7);
> [0.437781] lock(>i_sb->s_type->i_mutex_key#7);
> [0.443312]
> [0.443312] *** DEADLOCK ***
> [0.443312]
> [0.449593] May be due to missing lock nesting notation
> [0.449593]
> [0.456687] 1 lock held by swapper/1:
> [
Re: [tip:x86/mm] x86/kvm: Fix compile warning in kvm_register_steal_time()
On Mon, Feb 11, 2013 at 04:36:02AM -0800, tip-bot for Shuah Khan wrote:
> Commit-ID: 136867f517cbc3f8a91f035677911a6b503c3323
> Gitweb: http://git.kernel.org/tip/136867f517cbc3f8a91f035677911a6b503c3323
> Author: Shuah Khan
> AuthorDate: Tue, 5 Feb 2013 19:57:22 -0700
> Committer: Ingo Molnar
> CommitDate: Mon, 11 Feb 2013 11:04:31 +0100
>
> x86/kvm: Fix compile warning in kvm_register_steal_time()
>
> Fix the following compile warning in kvm_register_steal_time():
>
> CC arch/x86/kernel/kvm.o
> arch/x86/kernel/kvm.c: In function ‘kvm_register_steal_time’:
> arch/x86/kernel/kvm.c:302:3:
> warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but
> argument 3 has type ‘phys_addr_t’ [-Wformat]
>
> Introduced via:
>
> 5dfd486c4750 x86, kvm: Fix kvm's use of __pa() on percpu areas
> d76565344512 x86, mm: Create slow_virt_to_phys()
> f3c4fbb68e93 x86, mm: Use new pagetable helpers in try_preserve_large_page()
> 4cbeb51b860c x86, mm: Pagetable level size/shift/mask helpers
> a25b9316841c x86, mm: Make DEBUG_VIRTUAL work earlier in boot
>
> Signed-off-by: Shuah Khan
> Acked-by: Gleb Natapov
> Cc: Marcelo Tosatti
> Cc: Dave Hansen
> Cc: Rik van Riel
> Cc: shuahk...@gmail.com
> Cc: a...@redhat.com
> Cc: g...@redhat.com
> Cc: m...@redhat.com
> Link: http://lkml.kernel.org/r/1360119442.8356.8.camel@lorien2
> Signed-off-by: Ingo Molnar
> ---
> arch/x86/kernel/kvm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index aa7e58b..9cec202 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -298,8 +298,8 @@ static void kvm_register_steal_time(void)
> memset(st, 0, sizeof(*st));
>
> wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
> - printk(KERN_INFO "kvm-stealtime: cpu %d, msr %lx\n",
> - cpu, slow_virt_to_phys(st));
> + pr_info("kvm-stealtime: cpu %d, msr %llx\n",
> + cpu, (unsigned long long) slow_virt_to_phys(st));
I'm guessing this - like a bunch of other places in the kernel - should
be converted to the new %pa printk format once the last has been merged:
http://marc.info/?l=linux-kernel=135883371328510=2
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.8-rc7] PCI hotplug wakeup oops
On 12 February 2013 03:49, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 08:27:49 PM Rafael J. Wysocki wrote:
>> On Monday, February 11, 2013 12:01:37 PM Bjorn Helgaas wrote:
>> > [+cc Rafael]
>> >
>> > On Mon, Feb 11, 2013 at 10:08 AM, Daniel J Blueman
>> > wrote:
>> > > On 11 February 2013 21:03, Daniel J Blueman wrote:
>> > >> With 3.8-rc7, when unplugging the Thunderbolt ethernet adapter (bus 0a
>> > >> [1]) on a Macbook Pro 10,1, we see the PCIe port correctly released:
>> > >>
>> > >> pciehp :06:03.0:pcie24: Card not present on Slot(3)
>> > >> tg3 :0a:00.0: tg3_abort_hw timed out, TX_MODE_ENABLE will not
>> > >> clear MAC_TX_MODE=
>> > >> tg3 :0a:00.0 eth0: No firmware running
>> > >> tg3 :0a:00.0 eth0: Link is down
>> > >> [sched_delayed] sched: RT throttling activated
>> > >> pcieport :00:01.1: System wakeup enabled by ACPI
>> > >> pciehp :09:00.0:pcie24: unloading service driver pciehp
>> > >> pci_bus :0a: busn_res: [bus 0a] is released
>> > >> pci_bus :09: busn_res: [bus 09-0a] is released
>> > >>
>> > >> After some activity later (eg I can reproduce this by switching to a
>> > >> text console and back), often we'll see an oops:
>> > >>
>> > >> Unable to handle kernel paging request at 1070
>> > >> pci_pme_list_scan+0x3d/0xe0
>> > >> Call Trace:
>> > >> process_one_work+0x193
>> > >> ? process_one_work+0x131
>> > >> ? pci_pme_wakeup+0x60
>> > >> worker_thread+0x15d
>> > >>
>> > >> (gdb) list *(pci_pme_list_scan+0x3d)
>> > >> 0x8123f6dd is in pci_pme_list_scan (drivers/pci/pci.c:1556).
>> > >> 1551/*
>> > >> 1552 * If bridge is in low power
>> > >> state, the
>> > >> 1553 * configuration space of
>> > >> subordinate devices
>> > >> 1554 * may be not accessible
>> > >> 1555 */
>> > >> 1556if (bridge &&
>> > >> bridge->current_state != PCI_D0)
>> > >> 1557continue;
>> > >> 1558pci_pme_wakeup(pme_dev->dev,
>> > >> NULL);
>> > >> 1559} else {
>> > >> 1560list_del(_dev->list);
>> > >>
>> > >> Since a panic in vsnprintf happens after the oops (hence I can't catch
>> > >> it with EFI pstore), it is almost certainly significant heap
>> > >> corruption; this would explain why pme_dev became null (the load has
>> > >> been ordered ahead).
>> > >>
>> > >> I'll see what I can find out with memory poisoning and list debugging.
>> > >
>> > > Enabling a bunch of related debugging, we see pme_dev is non-null and:
>> > >
>> > > BUG: Unable to handle NULL pointer dereference at
>> > > pci_bus_read_config_word+0x6c
>> > > PGD 26314c067 PUD 2633f9067 PMD 0
>> > > Oops: [#1] SMP
>> > > pci_check_pme_status+0x4f
>> > > pci_pme_wakeup+0x21
>> > > pci_pme_list_scan+0xd5
>> > > process_one_work+0x1ca
>> > > ? process_one_work+0x160
>> > > ? pci_pme_wakeup+0x60
>> > > worker_thread+0x14e
>> > >
>> > > Anyway, it looks like the device being unplugged wasn't removed from
>> > > pci_pme_list as pci_pme_active(dev, false) wasn't called.
>> > >
>> > > From a quick review, I wasn't able to find the right place in the
>> > > call-chain which I only see releases the child busses and PCIe port
>> > > drivers. Anyone?
>> >
>> > It looks like drivers *add* devices to pci_pme_list when they use
>> > pci_enable_wake() or pci_wake_from_d3(). But many drivers never
>> > remove their devices, and I don't see any place where the core does it
>> > either. My guess is we need to remove it in pci_stop_dev() (we
>> > already do pcie_aspm_exit_link_state() there) or somewhere similar.
>>
>> Yes, we should call pci_pme_active(dev, false) somewhere in there I think.
>> It's fine to call that even if PME was not "active" before.
>
> Daniel, I wonder if the patch below helps?
>
> Rafael
>
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/pci/remove.c |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: test/drivers/pci/remove.c
> ===
> --- test.orig/drivers/pci/remove.c
> +++ test/drivers/pci/remove.c
> @@ -19,6 +19,8 @@ static void pci_free_resources(struct pc
>
> static void pci_stop_dev(struct pci_dev *dev)
> {
> + pci_pme_active(dev, false);
> +
> if (dev->is_added) {
> pci_proc_detach_device(dev);
> pci_remove_sysfs_dev_files(dev);
Indeed, the oops would prevent hitting the lockdep warning, which is a
secondary matter.
As it stands, this fix prevents the fatal oops, so IMHO is urgent
material for 3.8-final. I can't prove that is_added will always be
true, so let's stick with your patch.
Tested-by: Daniel J Blueman
--
Daniel J Blueman
--
To unsubscribe from this list: send the line
Re: [PATCH] sched: fix env->src_cpu for active migration
On 13 February 2013 15:08, Damien Wyart wrote: > * Vincent Guittot [2013-02-13 13:08]: >> Damien, >> Regarding your sched_domain config and especially the flags field, you >> should not be impacted by my patch because >> - need_active_balance is the only new place that use env->src_cpu in >> the load_balance function >> - and your machine will never test the condition: "env->src_cpu > >> env->dst_cpu" in need_active_balance because SD_ASYM_PACKING is not >> set in your config > >> Have you tested the patch with others that could have modified the >> load_balance function ? > > Yes, sorry, I should have been more precise in my initial report: your > patch was not applied on top of vanilla 3.8-rc7, but a few other patches > were also present. Seems the ones impacting load_balance are from > Frederic's nohz work > (http://git.kernel.org/?p=linux/kernel/git/frederic/linux-dynticks.git;a=shortlog;h=refs/heads/3.8-rc6-nohz4) > ok thanks for the pointer. i'm going to have a look > The patches from there modifying load_balance are: > - "sched: Update nohz rq clock before searching busiest group on load > balancing" > - "sched: Update clock of nohz busiest rq before balancing" > > In this test, I did not use any kernel parameter related to this > patchset (full_nohz, etc.). > > I am adding Frederic in Cc, not sure if the breakage is to be > investigated on your side or his... probably both > > > Thanks for your explanations, > -- > Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] printk: add pr_devel_once and pr_devel_ratelimited
Standardize pr_devel logging macros family by adding pr_devel_once and pr_devel_ratelimited. Signed-off-by: Mikhail Gruzdev Cc: Andrew Morton Cc: Greg Kroah-Hartman --- include/linux/printk.h | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/include/linux/printk.h b/include/linux/printk.h index 9afc01e..f282149 100644 --- a/include/linux/printk.h +++ b/include/linux/printk.h @@ -255,6 +255,15 @@ extern void dump_stack(void) __cold; printk_once(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) #define pr_cont_once(fmt, ...) \ printk_once(KERN_CONT pr_fmt(fmt), ##__VA_ARGS__) + +#if defined(DEBUG) +#define pr_devel_once(fmt, ...)\ + printk_once(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) +#else +#define pr_devel_once(fmt, ...)\ + no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) +#endif + /* If you are writing a driver, please use dev_dbg instead */ #if defined(DEBUG) #define pr_debug_once(fmt, ...)\ @@ -298,6 +307,15 @@ extern void dump_stack(void) __cold; #define pr_info_ratelimited(fmt, ...) \ printk_ratelimited(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) /* no pr_cont_ratelimited, don't do that... */ + +#if defined(DEBUG) +#define pr_devel_ratelimited(fmt, ...) \ + printk_ratelimited(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) +#else +#define pr_devel_ratelimited(fmt, ...) \ + no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) +#endif + /* If you are writing a driver, please use dev_dbg instead */ #if defined(DEBUG) #define pr_debug_ratelimited(fmt, ...) \ -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] virt_mmio: fix signature checking for BE guests
Using readl() to read the magic value and then memcmp() to check it
fails on BE, as bytes will be the other way around (by virtue of
the registers to follow the endianess of the guest).
Fix it by encoding the magic as an integer instead of a string.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Pawel Moll
Signed-off-by: Marc Zyngier
---
So I'm not completely sure this is the right fix, and I can imagine
other ways to cure the problem:
- Reading the MAGIC register byte by byte. Is that allowed? The spec
only says it is 32bit wide.
- Using __raw_readl() instead. Is that a generic enough API?
drivers/virtio/virtio_mmio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 31f966f..3811e94 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -470,7 +470,7 @@ static int virtio_mmio_probe(struct platform_device *pdev)
/* Check magic value */
magic = readl(vm_dev->base + VIRTIO_MMIO_MAGIC_VALUE);
- if (memcmp(, "virt", 4) != 0) {
+ if (magic != ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)) {
dev_warn(>dev, "Wrong magic value 0x%08lx!\n", magic);
return -ENODEV;
}
--
1.8.1.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/
[RFC][PATCH RT] acpi/rt: Convert acpi lock back to a raw_spinlock_t
We hit the following bug with 3.6-rt:
[5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
[5.898991] no locks held by swapper/3/0.
[5.898993] Modules linked in:
[5.898996] Pid: 0, comm: swapper/3 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
[5.898997] Call Trace:
[5.899011] [] __schedule_bug+0x67/0x90
[5.899028] [] __schedule+0x793/0x7a0
[5.899032] [] ? debug_rt_mutex_print_deadlock+0x50/0x200
[5.899034] [] schedule+0x29/0x70
[5.899036] BUG: scheduling while atomic: swapper/7/0/0x0002
[5.899037] no locks held by swapper/7/0.
[5.899039] [] rt_spin_lock_slowlock+0xe5/0x2f0
[5.899040] Modules linked in:
[5.899041]
[5.899045] [] ? _raw_spin_unlock_irqrestore+0x38/0x90
[5.899046] Pid: 0, comm: swapper/7 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
[5.899047] Call Trace:
[5.899049] [] rt_spin_lock+0x16/0x40
[5.899052] [] __schedule_bug+0x67/0x90
[5.899054] [] ? notifier_call_chain+0x80/0x80
[5.899056] [] __schedule+0x793/0x7a0
[5.899059] [] acpi_os_acquire_lock+0x1f/0x23
[5.899062] [] ? debug_rt_mutex_print_deadlock+0x50/0x200
[5.899068] [] acpi_write_bit_register+0x33/0xb0
[5.899071] [] schedule+0x29/0x70
[5.899072] [] ? acpi_read_bit_register+0x33/0x51
[5.899074] [] rt_spin_lock_slowlock+0xe5/0x2f0
[5.899077] [] acpi_idle_enter_bm+0x8a/0x28e
[5.899079] [] ? _raw_spin_unlock_irqrestore+0x38/0x90
[5.899081] [] ? this_cpu_load+0x1a/0x30
[5.899083] [] rt_spin_lock+0x16/0x40
[5.899087] [] cpuidle_enter+0x19/0x20
[5.899088] [] ? notifier_call_chain+0x80/0x80
[5.899090] [] cpuidle_enter_state+0x17/0x50
[5.899092] [] acpi_os_acquire_lock+0x1f/0x23
[5.899094] [] cpuidle899101] [] ?
As the acpi code disables interrupts in acpi_idle_enter_bm, and calls
code that grabs the acpi lock, it causes issues as the lock is currently
in RT a sleeping lock.
The lock was converted from a raw to a sleeping lock due to some
previous issues, and tests that showed it didn't seem to matter.
Unfortunately, it did matter for one of our boxes.
This patch converts the lock back to a raw lock. I've run this code on a
few of my own machines, one being my laptop that uses the acpi quite
extensively. I've been able to suspend and resume without issues.
But as it may have issues still with other hardware, I'm posting this as
an RFC.
Signed-off-by: Steven Rostedt
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 9eaf708..83d38ed 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1432,7 +1432,7 @@ void acpi_os_delete_lock(acpi_spinlock handle)
acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
{
acpi_cpu_flags flags;
- spin_lock_irqsave(lockp, flags);
+ raw_spin_lock_irqsave(lockp, flags);
return flags;
}
@@ -1442,7 +1442,7 @@ acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
void acpi_os_release_lock(acpi_spinlock lockp, acpi_cpu_flags flags)
{
- spin_unlock_irqrestore(lockp, flags);
+ raw_spin_unlock_irqrestore(lockp, flags);
}
#ifndef ACPI_USE_LOCAL_CACHE
diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index 7509be3..484cf8c 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -71,7 +71,7 @@
#define strtoul simple_strtoul
#define acpi_cache_tstruct kmem_cache
-#define acpi_spinlock spinlock_t *
+#define acpi_spinlock raw_spinlock_t *
#define acpi_cpu_flags unsigned long
#else /* !__KERNEL__ */
@@ -170,7 +170,7 @@ static inline void *acpi_os_acquire_object(acpi_cache_t *
cache)
\
if (lock) { \
*(__handle) = lock; \
- spin_lock_init(*(__handle));\
+ raw_spin_lock_init(*(__handle));\
} \
lock ? AE_OK : AE_NO_MEMORY;\
})
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property
On Wed, Feb 13, 2013 at 08:23:28AM -0600, Rob Herring wrote:
> On 02/12/2013 12:45 AM, Thierry Reding wrote:
> > On Mon, Feb 11, 2013 at 01:43:03PM -0600, Rob Herring wrote:
> >> On 02/11/2013 02:22 AM, Thierry Reding wrote:
> >>> From: Andrew Murray
>
> >>> @@ -13,6 +13,7 @@
> >>> #define OF_CHECK_COUNTS(na, ns) (OF_CHECK_ADDR_COUNT(na) && (ns) > 0)
> >>>
> >>> static struct of_bus *of_match_bus(struct device_node *np);
> >>> +static struct of_bus *of_find_bus(const char *name);
> >>
> >> Can you move this function up to avoid the forward declaration.
> >
> > It needs to be defined after the of_busses structure, which is defined
> > below the CONFIG_PCI block where of_pci_process_ranges() is defined. I'd
> > have to move that one as well and add another #ifdef CONFIG_PCI section.
> > If you prefer that I can do that.
>
> Okay, it's fine as is.
>
> >>> +static struct of_bus *of_find_bus(const char *name)
> >>> +{
> >>> + unsigned int i;
> >>> +
> >>> + for (i = 0; i < ARRAY_SIZE(of_busses); i++)
> >>> + if (strcmp(name, of_busses[i].name) == 0)
> >> ^
> >> space needed.
> >
> > I don't understand. Do you want the space to go between '.' and "name"?
>
> Must have been some dirt on my screen... Never mind.
>
> I'll apply these for 3.9.
Great, thanks!
Thierry
pgpgCL7pcTsJv.pgp
Description: PGP signature
[PATCH v2] staging/comedi: Fix undefined array subscript
In vmk80xx_do_insn_bits the local variable reg, which is used as an
index to the tx_buf array, can be used uninitialized if
- data[0] == 0
and
- devpriv->model != VMK8061_MODEL
-> we get into the else branch without having reg initialized.
Since the driver usually differentiates between VMK8061_MODEL and
VMK8055_MODEL it's safe to assume that VMK8055_DO_REG was meant as an
initial value.
And to avoid duplication we can move the assignments to the top.
Acked-by: Ian Abbott
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/vmk80xx.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index ebf2d48..eed46ee 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -675,8 +675,14 @@ static int vmk80xx_do_insn_bits(struct comedi_device *dev,
if (data[0])
dir |= DIR_OUT;
- if (devpriv->model == VMK8061_MODEL)
+ if (devpriv->model == VMK8061_MODEL) {
dir |= DIR_IN;
+ reg = VMK8061_DO_REG;
+ cmd = VMK8061_CMD_DO;
+ } else { /* VMK8055_MODEL */
+ reg = VMK8055_DO_REG;
+ cmd = VMK8055_CMD_WRT_AD;
+ }
retval = rudimentary_check(devpriv, dir);
if (retval)
@@ -688,14 +694,6 @@ static int vmk80xx_do_insn_bits(struct comedi_device *dev,
tx_buf = devpriv->usb_tx_buf;
if (data[0]) {
- if (devpriv->model == VMK8055_MODEL) {
- reg = VMK8055_DO_REG;
- cmd = VMK8055_CMD_WRT_AD;
- } else { /* VMK8061_MODEL */
- reg = VMK8061_DO_REG;
- cmd = VMK8061_CMD_DO;
- }
-
tx_buf[reg] &= ~data[0];
tx_buf[reg] |= (data[0] & data[1]);
@@ -706,7 +704,6 @@ static int vmk80xx_do_insn_bits(struct comedi_device *dev,
}
if (devpriv->model == VMK8061_MODEL) {
- reg = VMK8061_DO_REG;
tx_buf[0] = VMK8061_CMD_RD_DO;
retval = vmk80xx_read_packet(devpriv);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property
On 02/12/2013 12:45 AM, Thierry Reding wrote:
> On Mon, Feb 11, 2013 at 01:43:03PM -0600, Rob Herring wrote:
>> On 02/11/2013 02:22 AM, Thierry Reding wrote:
>>> From: Andrew Murray
>>> @@ -13,6 +13,7 @@
>>> #define OF_CHECK_COUNTS(na, ns)(OF_CHECK_ADDR_COUNT(na) && (ns) > 0)
>>>
>>> static struct of_bus *of_match_bus(struct device_node *np);
>>> +static struct of_bus *of_find_bus(const char *name);
>>
>> Can you move this function up to avoid the forward declaration.
>
> It needs to be defined after the of_busses structure, which is defined
> below the CONFIG_PCI block where of_pci_process_ranges() is defined. I'd
> have to move that one as well and add another #ifdef CONFIG_PCI section.
> If you prefer that I can do that.
Okay, it's fine as is.
>>> +static struct of_bus *of_find_bus(const char *name)
>>> +{
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(of_busses); i++)
>>> + if (strcmp(name, of_busses[i].name) == 0)
>> ^
>> space needed.
>
> I don't understand. Do you want the space to go between '.' and "name"?
Must have been some dirt on my screen... Never mind.
I'll apply these for 3.9.
Rob
>
> Thierry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regmap: irq: do not write mask register if it is not supported
On Wed, Feb 13, 2013 at 06:44:50PM +0530, Laxman Dewangan wrote:
> Ignore the mask register write if mask_base is not provided by
> regmap irq client. This is useful when regmap irq framework is
> used for the MFD's gpio interrupt support. Typically, gpio has
> two registers related to interrupt, one is for setting interrupt
Again you're talking about specific devices as though these are generic
things related to the class of device.
> for (i = 0; i < d->chip->num_regs; i++) {
> + if (!d->chip->mask_base)
> + goto skip_mask_reg_update;
> +
Why is this inside the loop?
I'd also expect us to return an error if a caller tries to enable or
disable an interrupt, or possibly to give different ops to the IRQ
subsystem, rather than just silently claim we did what we were asked.
signature.asc
Description: Digital signature
Re: [patch v4 01/18] sched: set SD_PREFER_SIBLING on MC domain to reduce a domain level
On 02/12/2013 06:11 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> The domain flag SD_PREFER_SIBLING was set both on MC and CPU domain at >> frist commit b5d978e0c7e79a, and was removed uncarefully when clear up >> obsolete power scheduler. Then commit 6956dc568 recover the flag on CPU >> domain only. It works, but it introduces a extra domain level since this >> cause MC/CPU different. >> >> So, recover the the flag in MC domain too to remove a domain level in >> x86 platform. May I still miss the points of this patch: Without this patch, the domain levels on my machines are: SMT, MC, CPU, NUMA with this patch, the domain levels are: SMT, MC, NUMA -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] ARM: OMAP2+: Export SoC information to userspace
On Mon, Feb 11, 2013 at 7:56 PM, Tony Lindgren wrote:
> * Ruslan Bilovol [130206 14:54]:
>> --- a/arch/arm/mach-omap2/io.c
>> +++ b/arch/arm/mach-omap2/io.c
>> @@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
>> omap2_common_pm_late_init();
>> omap4_pm_init();
>> omap2_clk_enable_autoidle_all();
>> + omap_soc_device_init();
>> }
>> #endif
>
> Looks like this should be called for all omaps instead
> of just omap4430?
>
> I suggest you create omap_common_init_late() that
> calls all the common init_late functions:
>
> static void __init omap_common_init_late(void)
> {
> omap_mux_late_init();
> omap2_common_pm_late_init();
> omap_soc_device_init();
> }
>
> Needs to be verified that these really are common to
> all omap2+ though :)
Yes, you are right, currently these functions are common to all
init_late callbacks that we have right now in io.c
I will prepare additional patch soon...
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix env->src_cpu for active migration
* Vincent Guittot [2013-02-13 13:08]: > Damien, > Regarding your sched_domain config and especially the flags field, you > should not be impacted by my patch because > - need_active_balance is the only new place that use env->src_cpu in > the load_balance function > - and your machine will never test the condition: "env->src_cpu > > env->dst_cpu" in need_active_balance because SD_ASYM_PACKING is not > set in your config > Have you tested the patch with others that could have modified the > load_balance function ? Yes, sorry, I should have been more precise in my initial report: your patch was not applied on top of vanilla 3.8-rc7, but a few other patches were also present. Seems the ones impacting load_balance are from Frederic's nohz work (http://git.kernel.org/?p=linux/kernel/git/frederic/linux-dynticks.git;a=shortlog;h=refs/heads/3.8-rc6-nohz4) The patches from there modifying load_balance are: - "sched: Update nohz rq clock before searching busiest group on load balancing" - "sched: Update clock of nohz busiest rq before balancing" In this test, I did not use any kernel parameter related to this patchset (full_nohz, etc.). I am adding Frederic in Cc, not sure if the breakage is to be investigated on your side or his... Thanks for your explanations, -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpio: Add device driver for GRGPIO cores and support custom accessors with gpio-generic
On 2013-02-13 08:05, Anton Vorontsov wrote:
On Tue, Feb 12, 2013 at 08:24:33AM +0100, Andreas Larsson wrote:
+ res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
+ regs = devm_request_and_ioremap(>dev, res);
Just wonder, is it safe to pass null res to devm_request_and_ioremap()?
Yes, and it is the preferred sequence of calls according to the
documentation of devm_request_and_ioremap.
+ label = kstrdup(np->full_name, GFP_KERNEL);
+ if (label)
+ gc->label = label;
Do we need to free label? If not, having a comment would be awesome. :)
And should we print a warning for !label case?
Yes, it needs to be freed, thanks! The !label case is kind of OK as the
gpio system assigns some other label if it is NULL, but I'll require it
instead to make things easier.
+static int grgpio_remove(struct platform_device *ofdev)
+{
+ dev_set_drvdata(>dev, NULL);
Is this really needed?
I guess not.
Thanks for the feedback! I take care of the other comments as well.
Cheers,
Andreas Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.6.11-rt29
Dear RT Folks,
I'm pleased to announce the 3.6.11-rt29 release.
Changes since 3.6.11-rt26:
1) Fix the RT highmem implementation on x86 this time really. The
issue I was seeing with kmap_atomic and friends was actually
when CONFIG_HIGHMEM was disabled. x8632 uses the atomic maps for
io_mapping_map_atomic_wc() even when CONFIG_HIGHMEM is off.
2) Modify the kmap_atomic per thread storage mechanism to reduce
code in switch_to
3) Rewrite RT highmem support for ARM with the kmap_atomic switch
mechanism like x86_32 uses it.
This is probably the last release for 3.6 from my side. Steven might
keep it maintained until the 3.8-rt stabilizes, but that's not yet
decided.
The delta patch against 3.6.11-rt28 is appended below and can be found
here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.11-rt28-rt29.patch.xz
The RT patch against 3.6.11 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.11-rt29.patch.xz
The split quilt queue is available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.11-rt29.tar.xz
Enjoy,
tglx
->
Index: linux-stable/arch/arm/include/asm/highmem.h
===
--- linux-stable.orig/arch/arm/include/asm/highmem.h
+++ linux-stable/arch/arm/include/asm/highmem.h
@@ -57,25 +57,10 @@ static inline void *kmap_high_get(struct
#ifdef CONFIG_HIGHMEM
extern void *kmap(struct page *page);
extern void kunmap(struct page *page);
-# ifndef CONFIG_PREEMPT_RT_FULL
extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
extern struct page *kmap_atomic_to_page(const void *ptr);
-# else
-# define kmap_atomic(page)\
- ({ pagefault_disable(); kmap(page); })
-
-# define kmap_atomic_pfn(pfn) \
- ({ pagefault_disable(); kmap(pfn_to_page(pfn)) })
-
-# define __kunmap_atomic(kvaddr) \
- do { kunmap(kmap_to_page(kvaddr)); pagefault_enable(); } while(0)
-
-# define kmap_atomic_to_page(kvaddr) \
- kmap_to_page(kvaddr)
-
-# endif
#endif
#endif
Index: linux-stable/arch/arm/mm/highmem.c
===
--- linux-stable.orig/arch/arm/mm/highmem.c
+++ linux-stable/arch/arm/mm/highmem.c
@@ -36,9 +36,9 @@ void kunmap(struct page *page)
}
EXPORT_SYMBOL(kunmap);
-#ifndef CONFIG_PREEMPT_RT_FULL
void *kmap_atomic(struct page *page)
{
+ pte_t pte = mk_pte(page, kmap_prot);
unsigned int idx;
unsigned long vaddr;
void *kmap;
@@ -77,7 +77,10 @@ void *kmap_atomic(struct page *page)
* in place, so the contained TLB flush ensures the TLB is updated
* with the new mapping.
*/
- set_top_pte(vaddr, mk_pte(page, kmap_prot));
+#ifdef CONFIG_PREEMPT_RT_FULL
+ current->kmap_pte[type] = pte;
+#endif
+ set_top_pte(vaddr, pte);
return (void *)vaddr;
}
@@ -111,6 +114,7 @@ EXPORT_SYMBOL(__kunmap_atomic);
void *kmap_atomic_pfn(unsigned long pfn)
{
+ pte_t pte = pfn_pte(pfn, kmap_prot);
unsigned long vaddr;
int idx, type;
@@ -122,7 +126,10 @@ void *kmap_atomic_pfn(unsigned long pfn)
#ifdef CONFIG_DEBUG_HIGHMEM
BUG_ON(!pte_none(get_top_pte(vaddr)));
#endif
- set_top_pte(vaddr, pfn_pte(pfn, kmap_prot));
+#ifdef CONFIG_PREEMPT_RT_FULL
+ current->kmap_pte[type] = pte;
+#endif
+ set_top_pte(vaddr, pte);
return (void *)vaddr;
}
@@ -136,4 +143,28 @@ struct page *kmap_atomic_to_page(const v
return pte_page(get_top_pte(vaddr));
}
+
+#if defined CONFIG_PREEMPT_RT_FULL
+void switch_kmaps(struct task_struct *prev_p, struct task_struct *next_p)
+{
+ int i;
+
+ /*
+* Clear @prev's kmap_atomic mappings
+*/
+ for (i = 0; i < prev_p->kmap_idx; i++) {
+ int idx = i + KM_TYPE_NR * smp_processor_id();
+
+ set_top_pte(__fix_to_virt(FIX_KMAP_BEGIN + idx), __pte(0));
+ }
+ /*
+* Restore @next_p's kmap_atomic mappings
+*/
+ for (i = 0; i < next_p->kmap_idx; i++) {
+ int idx = i + KM_TYPE_NR * smp_processor_id();
+
+ set_top_pte(__fix_to_virt(FIX_KMAP_BEGIN + idx),
+ next_p->kmap_pte[i]);
+ }
+}
#endif
Index: linux-stable/arch/x86/include/asm/highmem.h
===
--- linux-stable.orig/arch/x86/include/asm/highmem.h
+++ linux-stable/arch/x86/include/asm/highmem.h
@@ -56,39 +56,16 @@ extern unsigned long highstart_pfn, high
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
-extern void *kmap_high_prot(struct page *page, pgprot_t prot);
void *kmap(struct page *page);
void kunmap(struct page *page);
-#ifndef CONFIG_PREEMPT_RT_FULL
void *kmap_atomic_prot(struct
RE: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for delivering VMBUS interrupts
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Tuesday, February 12, 2013 7:31 PM > To: Greg KH > Cc: KY Srinivasan; x...@kernel.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; t...@linutronix.de; jbeul...@suse.com; b...@alien8.de > Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Use the new infrastructure for > delivering VMBUS interrupts > > On 02/06/2013 11:13 AM, Greg KH wrote: > > On Wed, Feb 06, 2013 at 07:25:59AM -0800, K. Y. Srinivasan wrote: > >> Use the infrastructure for delivering VMBUS interrupts using a > >> special vector. With this patch, we can now properly handle > >> the VMBUS interrupts that can be delivered on any CPU. Also, > >> turn on interrupt load balancing as well. > >> > >> This patch requires the infrastructure that was implemented in the patch: > >> X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts > >> > > > > Because of the dependancy, this should go through the x86 tree as well: > > Acked-by: Greg Kroah-Hartman > > > > This does not apply to v3.8-rc7 + the set of three vmbus patches for > x86. I take it there are additional dependencies -- K.Y., what do I > need here? Greg, Peter has checked in the infrastructural patches into v3.8-rc7. This version does not have the patches that upgraded the VMBUS protocol version to the win8 levels. How will the infrastructural patches get moved forward to the version where you have checked-in all the vmbus protocol updates: [PATCH 00/28] Drivers: hv: Update the Vmbus protocol. Now that Peter has checked in the needed patches, could you take this patch through your tree. Let me know, if you need, I can re-send this patch to you. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, 2013-02-13 at 15:36 +0200, Kasatkin, Dmitry wrote: > It should not be the only line in the policy. > Can you share full policy? > On Wed, Feb 13, 2013 at 3:29 PM, Vivek Goyal wrote: > > > > appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional Different use cases require different policies. Our concern is that appraising file integrity not be added to the kernel in an ad-hoc manner. This rule implements the intent of the original patches Vivek posted. We might personally disagree with the intent, but that is a totally separate discussion - one that should have been raised when he posted the original patches. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: iio: adc: add exynos5 adc driver under iio framwork
On 02/13/2013 02:53 PM, Naveen Krishna Ch wrote: [...] >>> ADC driver will use of_platform_populate() to populate the child nodes >>> (ntc thermistors in my case) >>> >>> I've modified the NTC driver to support DT. in probe >>> chan = iio_channel_get(>dev, "adcX"); >>> and using "id" field to use respective ADC channel to do the raw_read() >> >> The beauty of the interface is that the consumer doesn't need to know the >> number of the channel it is using. This is already fully described in the >> io-channels property. Since you only have one channel per consumer just use >> >> iio_chanel_get(>dev, NULL) > Right this helped me get the channels properly. > > I've a doubt in the driver posted at https://lkml.org/lkml/2013/1/24/2 > i don't need to use this anymore right use iio_map_array_register() Right. > > Thats so simple then.. Thanks Yes, if you are using devicetree you don't need to use iio_map_array_register() anymore :) - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging/comedi: Fix undefined array subscript
This patch works but it's nasty to re-intialize "reg" inside both
if else statements. Just do it once at the begining of the
function.
That means we would also delete the ininitialization from the if
side of the if else statement:
if (devpriv->model == VMK8061_MODEL) {
- reg = VMK8061_DO_REG;
tx_buf[0] = VMK8061_CMD_RD_DO;
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/11] mfd: twl-core: Collect global variables behind one private structure (global)
Hi Jon, On 02/12/2013 05:15 PM, Jon Hunter wrote: > > On 02/12/2013 01:26 AM, Peter Ujfalusi wrote: >> On 02/11/2013 09:22 PM, Jon Hunter wrote: >>> Good point. I just noticed that none of my omap2+ board were booting and >>> on omap3/4 I was the panic in the twl code. I can't say that I checked >>> the panic on omap2, so may be that was another problem? >> >> Do you have insights on the code path leading to a crash on OMAP3/4? I have >> been running this code on several boards (BeagleBoard, Zoom2, PandaBoard, >> Blaze) and have not seen a crash. > > Here is the panic log ... Thanks. > > [2.286132] Unable to handle kernel NULL pointer dereference at virtual > address > [2.294738] pgd = c0004000 > [2.297576] [] *pgd= > [2.301361] Internal error: Oops: 5 [#1] SMP ARM > [2.306243] Modules linked in: > [2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237 > #35) > [2.317169] PC is at twl_i2c_read+0x3c/0xec > [2.321563] LR is at twl_i2c_read+0x1c/0xec > [2.325988] pc : []lr : []psr: 8153 > [2.325988] sp : c702fed0 ip : fp : > [2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8 > [2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004 > [2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e > [2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment > kernel > [2.365051] Control: 10c5387d Table: 80004019 DAC: 0017 > [2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240) > [2.377410] Stack: (0xc702fed0 to 0xc703) > [2.382019] fec0: c0d42180 c0d429d0 > c70a7640 c07354c4 > [2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac > c07354c4 > [2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4 > c0cb8580 c06edee0 > [2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4 > 0001 > [2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4 > 0007 c0719798 > [2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c > 0007 0007 > [2.433654] ff80: c06e51c8 c04d26ec > > [2.442260] ffa0: c04d26f4 c00137b0 > > [2.450866] ffc0: > > [2.459472] ffe0: 0013 > 80fb6c10 71bbcd20 > [2.468078] [] (twl_i2c_read+0x3c/0xec) from [] > (omap3_twl_set_sr_bit+0x3c/0xb4) > [2.477722] [] (omap3_twl_set_sr_bit+0x3c/0xb4) from > [] (omap3_twl_init+0x2c/0x70) > [2.487518] [] (omap3_twl_init+0x2c/0x70) from [] > (omap_pmic_late_init+0x18/0x24) > [2.497222] [] (omap_pmic_late_init+0x18/0x24) from [] > (omap2_common_pm_late_init+0x18/0xd0) > [2.507934] [] (omap2_common_pm_late_init+0x18/0xd0) from > [] (omap3_init_late+0xc/0x18) > [2.518188] [] (omap3_init_late+0xc/0x18) from [] > (init_machine_late+0x1c/0x28) > [2.527740] [] (init_machine_late+0x1c/0x28) from [] > (do_one_initcall+0x100/0x16c) > [2.537536] [] (do_one_initcall+0x100/0x16c) from [] > (kernel_init_freeable+0xfc/0x1c8) > [2.547698] [] (kernel_init_freeable+0xfc/0x1c8) from > [] (kernel_init+0x8/0xe4) > [2.557250] [] (kernel_init+0x8/0xe4) from [] > (ret_from_fork+0x14/0x24) This is exactly the sort of thing which should not ever existed in the first place... The code in omap_twl.c, especially the omap3_twl_set_sr_bit() function is executed in .init_late of the board. If the twl stack is not up by then we are going to have issues. Right now I don't see how to solve this (the call chain is related to smartreflex) but IMHO we should not have these 'random' twl_write calls spread across the kernel without integrating them to the twl stack in a proper manner. What I mean is that we should only have twl_* calls from drivers, which has been created by the twl-core MFD core. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rwsem: Implement writer lock-stealing
On 02/09/2013 10:45 AM, Michel Lespinasse wrote: > This proposal implements writer lock stealing in lib/rwsem.c, just as > Alex Shi's earlier proposal did for the simpler lib/rwsem-spinlock.c Ops, my patch in tip/urgent is for rwsem. Yuanhan's patch is for rwsem-spinlock. Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regmap: irq: Add support for interrupt type
On Wed, Feb 13, 2013 at 06:44:49PM +0530, Laxman Dewangan wrote:
> Most of the MFD module have the GPIO and gpio interrupt is
> enabled/disabled through the rising/falling edge type. There
> is no specific mask enable/disable registers for GPIO submodules.
>
> Extend the regmap irq to support the irq_set_type() so that
> gpio submodule of MFD devices can use the regmap-irq framework
> for their interrupt registration.
This commit message needs to be rewritten for comprehensibility, MFD has
nothing to do with this - it's something to do with your particular
hardware that you're trying to support. Describe the hardware feature,
not the subsystem your hardware happens to be used in.
> + switch (type) {
> + case IRQ_TYPE_EDGE_FALLING:
> + d->type_buf[reg] |= irq_data->type_falling_mask;
> + break;
> +
> + case IRQ_TYPE_EDGE_RISING:
> + d->type_buf[reg] |= irq_data->type_rising_mask;
> + break;
> +
> + case IRQ_TYPE_EDGE_BOTH:
> + d->type_buf[reg] |= (irq_data->type_falling_mask |
> + irq_data->type_rising_mask);
> + break;
This should handle the case where an output type is not supported, for
example if the device only supports falling edge. It'd also seem
sensible to have an explicit value to set for each trigger type rather
than reyling on the device using separate bits for everything - you
might see an encoding like 0 for falling, 1 for rising, 2 for both and 3
for level for example.
signature.asc
Description: Digital signature
Re: iio: adc: add exynos5 adc driver under iio framwork
On 13 February 2013 19:00, Lars-Peter Clausen wrote:
> On 02/13/2013 02:16 PM, Naveen Krishna Ch wrote:
>> Please ignore the unfinished previous mail.
>>
>>
>>
>> On 13 February 2013 08:18, Naveen Krishna Ch
>> wrote:
>>> On 13 February 2013 02:37, Guenter Roeck wrote:
On Wed, Jan 23, 2013 at 04:58:06AM -, Naveen Krishna Chatradhi wrote:
> This patch add an ADC IP found on EXYNOS5 series socs from Samsung.
> Also adds the Documentation for device tree bindings.
>
> Signed-off-by: Naveen Krishna Chatradhi
>
> ---
> Changes since v1:
>
> 1. Fixed comments from Lars
> 2. Added support for ADC on EXYNOS5410
>
> Changes since v2:
>
> 1. Changed the instance name for (struct iio_dev *) to indio_dev
> 2. Changed devm_request_irq to request_irq
>
> Few doubts regarding the mappings and child device handling.
> Kindly, suggest me better methods.
>
> .../bindings/arm/samsung/exynos5-adc.txt | 37 ++
> drivers/iio/adc/Kconfig|7 +
> drivers/iio/adc/Makefile |1 +
> drivers/iio/adc/exynos5_adc.c | 464
>
> 4 files changed, 509 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
> create mode 100644 drivers/iio/adc/exynos5_adc.c
>
> diff --git
> a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
> b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
> new file mode 100644
> index 000..9a5b515
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
> @@ -0,0 +1,37 @@
> +Samsung Exynos5 Analog to Digital Converter bindings
> +
> +Required properties:
> +- compatible:Must be "samsung,exynos5250-adc" for
> exynos5250 controllers.
> +- reg: Contains ADC register address range (base
> address and
> + length).
> +- interrupts:Contains the interrupt information for the
> timer. The
> + format is being dependent on which interrupt
> controller
> + the Samsung device uses.
> +
> +Note: child nodes can be added for auto probing from device tree.
> +
> +Example: adding device info in dtsi file
> +
> +adc@12D1 {
> + compatible = "samsung,exynos5250-adc";
> + reg = <0x12D1 0x100>;
> + interrupts = <0 106 0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +};
> +
> +
> +Example: Adding child nodes in dts file
> +
> +adc@12D1 {
> +
> + /* NTC thermistor is a hwmon device */
> + ncp15wb473@0 {
> + compatible = "ntc,ncp15wb473";
> + reg = <0x0>;
> + pullup-uV = <180>;
> + pullup-ohm = <47000>;
> + pulldown-ohm = <0>;
> + };
> +};
How about:
adc: adc@12D1 {
compatible = "samsung,exynos5250-adc";
reg = <0x12D1 0x100>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
};
...
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
reg = <0x0>; /* is this needed ? */
io-channels = < 0>;
io-channel-names = "adc";
pullup-uV = <180>; /* uV or uv ? */
pullup-ohm = <47000>;
pulldown-ohm = <0>;
};
The ncp15wb473 driver would then use either iio_channel_get_all() to get
the iio
channel list or, if it only supports one adc channel per instance,
iio_channel_get().
In that context, it would probably make sense to rework the ntc_thermistor
driver to support both DT as well as direct instantiation using access
functions
and platform data (as it does today).
Also see https://patchwork.kernel.org/patch/2112171/.
>>
>> Hello Guenter,
>>
>> I've rebase my adc driver on top of your (OF for IIO patch)
>>
>> My setup is like the below one. kindly, help me find the right device
>> tree node params
>>
>> One ADC controller with 8 channels,
>> 4 NTC thermistors are connected to channel 3, 4, 5 and 6 of ADC
>> respectively
>>
>> ADC ch - 0
>> ADC ch - 1
>> ADC ch - 2
>> ADC ch - 3 --NTC
>> ADC ch - 4 --NTC
>> ADC ch - 5 --NTC
>> ADC ch - 6 --NTC
>> ADC ch - 7
>>
>> I've started off with something like this.
>>
>> adc0: adc@12D1 {
>> compatible = "samsung,exynos5250-adc";
>> reg =
Re: [PATCH] IB/lmx4: silence GCC warning
On 10/29/12 10:50, Paul Bolle wrote: On Wed, 2012-10-10 at 09:23 +0200, Jack Morgenstein wrote: You could use: u16 uninitialized_var(vlan); instead. I guess we'd better just wait and see whether uninitialized_var() survives before discussing your suggestion (see the thread starting at https://lkml.org/lkml/2012/10/26/508 ). Although this in the special QP data flow, I still prefer to avoid adding extra code (even setting initial values at procedure entry). The line above will also do the job. "uninitialized_var" is used elsewhere in the driver. See, for example, mlx4_ib_post_send() in the same file (qp.c). (replying to an e-mail of a few months ago) If there are no further objections I'd like to see this patch to go upstream. It fixes an annoying compiler warning and I don't think that this patch has a negative performance impact. Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote: > It should not be the only line in the policy. So a single rule is not allowed or kernel has imposed more rules internally. > Can you share full policy? How do I get to full policy. Is there an interface I can read it from? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Various PCI-related device tree helpers
Hello, On Mon, 11 Feb 2013 09:22:16 +0100, Thierry Reding wrote: > Hi, > > These patches add a few device tree helpers that are used are partially > shared by Thomas' Marvell PCIe controller and my Tegra PCIe controller > series. In an attempt to decrease the number of dependencies between > trees, it would be nice to get these in for 3.9. There are a few ARM > specific patches that the series depend on which have also been > submitted and will hopefully make it into 3.9 so we can use the 3.9 > cycle to focus on getting the driver patches merged. > > Thierry > > Andrew Murray (1): > of/pci: Provide support for parsing PCI DT ranges property > > Thierry Reding (3): > of/pci: Add of_pci_get_devfn() function > of/pci: Add of_pci_get_bus() function > of/pci: Add of_pci_parse_bus_range() function > > drivers/of/address.c | 63 > drivers/of/of_pci.c| 80 > +++--- > include/linux/of_address.h | 9 ++ > include/linux/of_pci.h | 3 ++ > 4 files changed, 150 insertions(+), 5 deletions(-) For the patches: Tested-by: Thomas Petazzoni As Thierry said, we are also using those patches for the Marvell PCIe driver, so it would be really nice to have them in 3.9 so that we have a bit less patches to worry about when submitting our PCIe driver for 3.10. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/comedi: Fix undefined array subscript
On 2013-02-13 11:56, Ian Abbott wrote: For a digital output subdevice, you could either read back the current values directly from the hardware or just use the value previously written. The Velleman K8055 doesn't have a command to read back the digital outputs from the hardware, so the last written value has to be used. But what if the digital outputs have never been written (or the analog outputs have never been written, since the same command updates all analog and digital channels)? A "reset" command is sent to the hardware on initialization by vmk80xx_reset_device() (only called for the K8055), but I don't know what effect this has on the actual digital (and analog) outputs (though I could find out easily enough as we appear to have one of these kits (assembled) lying around in the office). If necessary, we may have to also send a "write" command on initialization to make the hardware outputs match the initial software state. I've had a quick play with a K8055 and it seems the "reset" command issued during hardware initialization has no effect on the digital outputs. (I tested this by setting some digital outputs with comedi instructions - there are some handy LEDs on the board that light up or not according to the state of the digital outputs - then rmmod'ing and modprobe'ing the vmk80xx module - the LEDs remained in the same state.) Since we can't read back the outputs on this board we should initialize them to a known state. I'll submit some patches later. Nothing to do with the patch in this thread, which has my Ack. Acked-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] X.509: Support parse long form of length octets in Authority Key Identifier
Lee, Chun-Yi wrote:
> Signed-off-by: Lee, Chun-Yi
Without the comma, please.
> + /* Short Form length */
> + if (vlen <= 127) {
> +
> + if (v[1] != vlen - 2 ||
There's an unnecessary blank line there. I would also move the comment inside
the if-body.
> + int sub = v[1] - 0x80;
I recommend you use an unsigned int or size_t variable.
Also, you should use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
> + v += 4;
> + key_len = v[3];
Are you sure that is correct? You altered v before doing v[3]. I would stick
with key_len = vlen - 4.
> + /* calculate the length from subsequent octet */
"... octets".
> + seq_len |= v[2 + i];
Add 2 to v before entering the loop.
> + /* check vlen should not less then length of keyid */
vlen should be exactly equal to key id, shouldn't it? Leastways, that's what
you're checking...
> + v += (4 + sub);
> + key_len = v[3 + sub];
Again, this doesn't look right. Besides, you should be able to work out
key_len from vlen, subtracting the metadata size.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, 2013-02-13 at 15:13 +0200, Kasatkin, Dmitry wrote:
> On Wed, Feb 13, 2013 at 2:56 PM, Mimi Zohar wrote:
> > On Wed, 2013-02-13 at 14:31 +0200, Kasatkin, Dmitry wrote:
> >> On Mon, Feb 11, 2013 at 10:11 PM, Vivek Goyal wrote:
> >
> >> > @@ -158,7 +165,8 @@ int ima_appraise_measurement(int func, struct
> >> > integrity_iint_cache *iint,
> >> > }
> >> > switch (xattr_value->type) {
> >> > case IMA_XATTR_DIGEST:
> >> > - if (iint->flags & IMA_DIGSIG_REQUIRED) {
> >> > + if (iint->flags & IMA_DIGSIG_REQUIRED ||
> >> > + iint->flags & IMA_DIGSIG_OPTIONAL) {
> >> > cause = "IMA signature required";
> >> > status = INTEGRITY_FAIL;
> >> > break;
> >>
> >> This looks a bit odd... If "optional" signature is missing - we fail..
> >> It is optional... Why we should fail?
> >
> > 'imasig_optional' does not only mean that the signature is optional, but
> > also implies that it has to be a digital signature, not a hash. This
> > latter part is what IMA_DIGSIG_REQUIRED means.
> >
> > If 'imasig_optional' set both 'IMA_DIGSIG_OPTIONAL' and
> > 'IMA_DIGSIG_REQUIRED', then this change wouldn't be necessary.
> >
> > IMA_DIGSIG_REQUIRED would enforce that it is a signature.
> > IMA_DIGSIG_OPTIONAL would fail only for files with invalid signatures.
> >
>
> It sounds odd that optional signature is actually required.
> Optional for me means that it may be there or may be not.
> If it is not there, then it may be hash or nothing.
>
> I see it is more logical if it is "appraise_type=optional",
> which means that we might have no xattr value, hash or signature.
> It if happens to be a signature, then IMA_DIGSIG flag will be set.
Right, 'appraise_type=' could have been defined either as a comma
separated list of options (eg. appraise_type=imassig,optional) or, as
Vivek implemented, a new option. Eventually, we will need to extend
'appraise_type=' (eg. required algorithm), but for now I don't have a
problem with the new option.
thanks,
Mimi
> I asked Vivek to send a policy file he uses in his system.
> I would like to see how system configured as a whole...
>
> - Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/13] drivers: mailbox: framework creation
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote: > On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: > > > I have hosted the series at [3]. > > [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox > > Suman, I suggest you ask Stepgen Rothwell to include this > branch into the linux-next tree, so we can get some > rotation of this stuff in preparation for the v3.10 merge > window. (It's not going in now anyway.) Best wait until after v3.9-rc1 - remember that linux-next is supposed to be a staging tree for the _next_ merge window 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] gpio: devm_gpio_* support should not depend on GPIOLIB
Sorry for the late response due to Chinese New Year Holidays here. On Sun, Feb 10, 2013 at 07:46:30AM +0300, Max Filippov wrote: > On Sat, Jan 19, 2013 at 2:33 AM, Linus Walleij > wrote: > > On Fri, Jan 18, 2013 at 8:57 AM, Shawn Guo wrote: > > > >> Some architectures (e.g. blackfin) provide gpio API without requiring > >> GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions > >> should also work for these architectures, since they do not really > >> depend on GPIOLIB. > >> > >> Add a new option GPIO_DEVRES (enabled by default) to control the build > >> of devres.c. It also removes the empty version of devm_gpio_* > >> functions for !GENERIC_GPIO build from linux/gpio.h, and moves the > >> function declarations from asm-generic/gpio.h into linux/gpio.h. > >> > >> Signed-off-by: Shawn Guo > > > > OK I removed the old version of the patch and pushed this instead. > > Hi, > > this patch causes the following errors for xtensa defconfig build: > I assume this is a build of arch/xtensa/common_defconfig. > include/asm-generic/gpio.h:265:2: error: implicit declaration of > function '__gpio_get_value' [-Werror=implicit-function-declaration] > include/asm-generic/gpio.h:271:2: error: implicit declaration of > function '__gpio_set_value' [-Werror=implicit-function-declaration] > include/linux/gpio.h:60:90: error: redefinition of 'gpio_cansleep' > include/linux/gpio.h:62:2: error: implicit declaration of function > '__gpio_cansleep' [-Werror=implicit-function-declaration] > include/linux/gpio.h:67:2: error: implicit declaration of function > '__gpio_to_irq' [-Werror=implicit-function-declaration] > drivers/gpio/devres.c:26:2: error: implicit declaration of function > 'gpio_free' [-Werror=implicit-function-declaration] > drivers/gpio/devres.c:60:2: error: implicit declaration of function > 'gpio_request' [-Werror=implicit-function-declaration] > drivers/gpio/devres.c:90:2: error: implicit declaration of function > 'gpio_request_one' [-Werror=implicit-function-declaration] > I'm not sure why GENERIC_GPIO is needed for this build at all. At least, with the change below, everything seems building fine with common_defconfig. Shawn diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index 13358e1..cfc41f3 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -31,9 +31,6 @@ config RWSEM_XCHGADD_ALGORITHM config GENERIC_HWEIGHT def_bool y -config GENERIC_GPIO - def_bool y - config ARCH_HAS_ILOG2_U32 def_bool 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/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
It should not be the only line in the policy.
Can you share full policy?
Thanks,
Dmitry
On Wed, Feb 13, 2013 at 3:29 PM, Vivek Goyal wrote:
> On Wed, Feb 13, 2013 at 02:14:55PM +0200, Kasatkin, Dmitry wrote:
>> Hello Vivek,
>>
>> Can you please send to us how your IMA policy looks like.
>
> Hi Dmitry,
>
> For testing purposes, I am using following.
>
> appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional
>
> I set this using /sys/kernel/security/policy interface after boot.
>
> Thanks
> Vivek
>
>>
>> Thanks,
>> Dmitry
>>
>> On Tue, Feb 12, 2013 at 8:57 PM, Vivek Goyal wrote:
>> > On Tue, Feb 12, 2013 at 01:52:03PM -0500, Vivek Goyal wrote:
>> >> On Tue, Feb 12, 2013 at 12:14:07PM -0500, Mimi Zohar wrote:
>> >>
>> >> [..]
>> >> > > > > --- a/security/integrity/ima/ima_appraise.c
>> >> > > > > +++ b/security/integrity/ima/ima_appraise.c
>> >> > > > > @@ -124,19 +124,26 @@ int ima_appraise_measurement(int func,
>> >> > > > > struct integrity_iint_cache *iint,
>> >> > > > > enum integrity_status status = INTEGRITY_UNKNOWN;
>> >> > > > > const char *op = "appraise_data";
>> >> > > > > char *cause = "unknown";
>> >> > > > > - int rc;
>> >> > > > > + int rc, audit_info = 0;
>> >> > > > >
>> >> > > > > if (!ima_appraise)
>> >> > > > > return 0;
>> >> > > > > - if (!inode->i_op->getxattr)
>> >> > > > > + if (!inode->i_op->getxattr) {
>> >> > > > > + /* getxattr not supported. file couldn't have been
>> >> > > > > signed */
>> >> > > > > + if (iint->flags & IMA_DIGSIG_OPTIONAL)
>> >> > > > > + return INTEGRITY_PASS;
>> >> > > > > return INTEGRITY_UNKNOWN;
>> >> > > > > + }
>> >> > > > >
>> >> > > >
>> >> > > > Please don't change the result of the appraisal like this. A single
>> >> > > > change can be made towards the bottom of process_measurement().
>> >> > >
>> >> > > I don't want to pass integrity in all cases of INTEGRITY_UNKNOWN. So
>> >> > > I can probably maintain a bool variable, say pass_appraisal, and set
>> >> > > that here and at the end of function, parse that variable and change
>> >> > > the status accordingly.
>> >> >
>> >> > process_measurement() is the only caller of ima_appraise_measurement().
>> >> > Leave the results of ima_appraise_measurement() alone. There's already
>> >> > code at the end of process_measurement() which decides what to return.
>> >> > Just modify it based on the appraisal results.
>> >>
>> >
>> > If we do this, audit logs will be filled with integrity unknown failures.
>> > As each unsigned executable file will fail appraisal with INTEGRITY_UNKNOWN
>> > and an audit message will be logged.
>> >
>> > Thanks
>> > Vivek
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> > linux-security-module" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/13] drivers: mailbox: framework creation
On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: > I have hosted the series at [3]. > [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Suman, I suggest you ask Stepgen Rothwell to include this branch into the linux-next tree, so we can get some rotation of this stuff in preparation for the v3.10 merge window. (It's not going in now anyway.) If it proves to survive some smoke testing there, I suggest we proceed to pull this into the ARM SoC tree early in the v3.10 kernel cycle, since all the dependencies will be in ARM SoC anyway. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kvm: Add MSR_AMD64_BU_CFG2 to the list of ignored MSRs
On Wed, Feb 13, 2013 at 02:10:02PM +0200, Gleb Natapov wrote: > > > Is your guest compiled without PV support? With PV Linux traps #GP for > > > all MSRs and it saves us in more than one places. > > > > Yes, CONFIG_PARAVIRT_GUEST is not set on the guest kernel. > > > Thanks. It does not mean that the patch should not be applied though. Right, but, come to think of it, adding an MSR each time to those functions could turn out to be a PITA. The PV solution with trapping on the MSR accesses might be better so maybe CONFIG_KVM should do select KVM_GUEST ? This is even a good forward-looking solution. > I cannot seems to find the documentation for the MSR anywhere, do you > have a pointer? http://support.amd.com/us/Processor_TechDocs/31116.pdf, p.438 Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 02:14:55PM +0200, Kasatkin, Dmitry wrote:
> Hello Vivek,
>
> Can you please send to us how your IMA policy looks like.
Hi Dmitry,
For testing purposes, I am using following.
appraise fowner=0 func=BPRM_CHECK appraise_type=imasig_optional
I set this using /sys/kernel/security/policy interface after boot.
Thanks
Vivek
>
> Thanks,
> Dmitry
>
> On Tue, Feb 12, 2013 at 8:57 PM, Vivek Goyal wrote:
> > On Tue, Feb 12, 2013 at 01:52:03PM -0500, Vivek Goyal wrote:
> >> On Tue, Feb 12, 2013 at 12:14:07PM -0500, Mimi Zohar wrote:
> >>
> >> [..]
> >> > > > > --- a/security/integrity/ima/ima_appraise.c
> >> > > > > +++ b/security/integrity/ima/ima_appraise.c
> >> > > > > @@ -124,19 +124,26 @@ int ima_appraise_measurement(int func,
> >> > > > > struct integrity_iint_cache *iint,
> >> > > > > enum integrity_status status = INTEGRITY_UNKNOWN;
> >> > > > > const char *op = "appraise_data";
> >> > > > > char *cause = "unknown";
> >> > > > > - int rc;
> >> > > > > + int rc, audit_info = 0;
> >> > > > >
> >> > > > > if (!ima_appraise)
> >> > > > > return 0;
> >> > > > > - if (!inode->i_op->getxattr)
> >> > > > > + if (!inode->i_op->getxattr) {
> >> > > > > + /* getxattr not supported. file couldn't have been
> >> > > > > signed */
> >> > > > > + if (iint->flags & IMA_DIGSIG_OPTIONAL)
> >> > > > > + return INTEGRITY_PASS;
> >> > > > > return INTEGRITY_UNKNOWN;
> >> > > > > + }
> >> > > > >
> >> > > >
> >> > > > Please don't change the result of the appraisal like this. A single
> >> > > > change can be made towards the bottom of process_measurement().
> >> > >
> >> > > I don't want to pass integrity in all cases of INTEGRITY_UNKNOWN. So
> >> > > I can probably maintain a bool variable, say pass_appraisal, and set
> >> > > that here and at the end of function, parse that variable and change
> >> > > the status accordingly.
> >> >
> >> > process_measurement() is the only caller of ima_appraise_measurement().
> >> > Leave the results of ima_appraise_measurement() alone. There's already
> >> > code at the end of process_measurement() which decides what to return.
> >> > Just modify it based on the appraisal results.
> >>
> >
> > If we do this, audit logs will be filled with integrity unknown failures.
> > As each unsigned executable file will fail appraisal with INTEGRITY_UNKNOWN
> > and an audit message will be logged.
> >
> > Thanks
> > Vivek
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-security-module" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iio: adc: add exynos5 adc driver under iio framwork
On 02/13/2013 02:16 PM, Naveen Krishna Ch wrote:
> Please ignore the unfinished previous mail.
>
>
>
> On 13 February 2013 08:18, Naveen Krishna Ch
> wrote:
>> On 13 February 2013 02:37, Guenter Roeck wrote:
>>> On Wed, Jan 23, 2013 at 04:58:06AM -, Naveen Krishna Chatradhi wrote:
This patch add an ADC IP found on EXYNOS5 series socs from Samsung.
Also adds the Documentation for device tree bindings.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
1. Fixed comments from Lars
2. Added support for ADC on EXYNOS5410
Changes since v2:
1. Changed the instance name for (struct iio_dev *) to indio_dev
2. Changed devm_request_irq to request_irq
Few doubts regarding the mappings and child device handling.
Kindly, suggest me better methods.
.../bindings/arm/samsung/exynos5-adc.txt | 37 ++
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/exynos5_adc.c | 464
4 files changed, 509 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
create mode 100644 drivers/iio/adc/exynos5_adc.c
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
new file mode 100644
index 000..9a5b515
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
@@ -0,0 +1,37 @@
+Samsung Exynos5 Analog to Digital Converter bindings
+
+Required properties:
+- compatible:Must be "samsung,exynos5250-adc" for
exynos5250 controllers.
+- reg: Contains ADC register address range (base
address and
+ length).
+- interrupts:Contains the interrupt information for the
timer. The
+ format is being dependent on which interrupt
controller
+ the Samsung device uses.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc@12D1 {
+ compatible = "samsung,exynos5250-adc";
+ reg = <0x12D1 0x100>;
+ interrupts = <0 106 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D1 {
+
+ /* NTC thermistor is a hwmon device */
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ reg = <0x0>;
+ pullup-uV = <180>;
+ pullup-ohm = <47000>;
+ pulldown-ohm = <0>;
+ };
+};
>>>
>>> How about:
>>>
>>> adc: adc@12D1 {
>>> compatible = "samsung,exynos5250-adc";
>>> reg = <0x12D1 0x100>;
>>> interrupts = <0 106 0>;
>>> #io-channel-cells = <1>;
>>> };
>>>
>>> ...
>>>
>>> ncp15wb473@0 {
>>> compatible = "ntc,ncp15wb473";
>>> reg = <0x0>; /* is this needed ? */
>>> io-channels = < 0>;
>>> io-channel-names = "adc";
>>> pullup-uV = <180>; /* uV or uv ? */
>>> pullup-ohm = <47000>;
>>> pulldown-ohm = <0>;
>>> };
>>>
>>> The ncp15wb473 driver would then use either iio_channel_get_all() to get
>>> the iio
>>> channel list or, if it only supports one adc channel per instance,
>>> iio_channel_get().
>>>
>>> In that context, it would probably make sense to rework the ntc_thermistor
>>> driver to support both DT as well as direct instantiation using access
>>> functions
>>> and platform data (as it does today).
>>>
>>> Also see https://patchwork.kernel.org/patch/2112171/.
>
> Hello Guenter,
>
> I've rebase my adc driver on top of your (OF for IIO patch)
>
> My setup is like the below one. kindly, help me find the right device
> tree node params
>
> One ADC controller with 8 channels,
> 4 NTC thermistors are connected to channel 3, 4, 5 and 6 of ADC respectively
>
> ADC ch - 0
> ADC ch - 1
> ADC ch - 2
> ADC ch - 3 --NTC
> ADC ch - 4 --NTC
> ADC ch - 5 --NTC
> ADC ch - 6 --NTC
> ADC ch - 7
>
> I've started off with something like this.
>
> adc0: adc@12D1 {
> compatible = "samsung,exynos5250-adc";
> reg = <0x12D1 0x100>;
> interrupts = <0 106 0>;
> #io-channel-cells = <1>;
> };
>
> adc0: adc@12D1 {
This is a copy paste error, right? you only have one dt
[PATCH] of: spi: Return error from of_spi_register_master on bad "cs-gpios" property
This makes sure that an error is returned on an incorrectly formed "cs-gpios" property, but reports success when the "cs-gpios" property is well formed or missing. When holes in the cs-gpios property phandle list is used to indicate that some other form of chipselect is to be used it is important that failure to read a broken "cs-gpios" property does not silently fail leading to the spi controller to use an unintended chipselect. Signed-off-by: Andreas Larsson --- Can only be applied to devicetree/next as it builds upon the "of: Add helper for counting phandle refernces" patch series. drivers/spi/spi.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 21c4748..9b5f024 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1068,8 +1068,11 @@ static int of_spi_register_master(struct spi_master *master) nb = of_gpio_named_count(np, "cs-gpios"); master->num_chipselect = max(nb, (int)master->num_chipselect); - if (nb < 1) + /* Return error only for an incorrectly formed cs-gpios property */ + if (nb == 0 || nb == -ENOENT) return 0; + else if (nb < 0) + return nb; cs = devm_kzalloc(>dev, sizeof(int) * master->num_chipselect, -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 01/18] sched: set SD_PREFER_SIBLING on MC domain to reduce a domain level
On 02/12/2013 06:11 PM, Peter Zijlstra wrote: > On Thu, 2013-01-24 at 11:06 +0800, Alex Shi wrote: >> The domain flag SD_PREFER_SIBLING was set both on MC and CPU domain at >> frist commit b5d978e0c7e79a, and was removed uncarefully when clear up >> obsolete power scheduler. Then commit 6956dc568 recover the flag on CPU >> domain only. It works, but it introduces a extra domain level since this >> cause MC/CPU different. >> >> So, recover the the flag in MC domain too to remove a domain level in >> x86 platform. Peter, I am very very happy to see you again! :) > > This fails to clearly state why its desirable.. I'm guessing its because > we should use sibling cache domains before sibling threads, right? No, the flags set on MC/CPU domain, but is checked in their parents balancing, like in NUMA domain. Without the flag, will cause NUMA domain imbalance. like on my 2 sockets NHM EP: 3 of 4 tasks were assigned on socket 0(lcpu, 10, 12, 14) In this case, update_sd_pick_busiest() need a reduced group_capacity to return true: if (sgs->sum_nr_running > sgs->group_capacity) return true; then numa domain balancing get chance to start. - 05:00:28 AM CPU%usr %nice %idle 05:00:29 AM all 25.000.00 74.94 05:00:29 AM00.000.00 99.00 05:00:29 AM10.000.00 100.00 05:00:29 AM20.000.00 100.00 05:00:29 AM30.000.00 100.00 05:00:29 AM40.000.00 100.00 05:00:29 AM50.000.00 100.00 05:00:29 AM60.000.00 100.00 05:00:29 AM70.000.00 100.00 05:00:29 AM80.000.00 100.00 05:00:29 AM90.000.00 100.00 05:00:29 AM 10 100.000.00 0.00 05:00:29 AM 110.000.00 100.00 05:00:29 AM 12 100.000.00 0.00 05:00:29 AM 130.000.00 100.00 05:00:29 AM 14 100.000.00 0.00 05:00:29 AM 15 100.000.00 0.00 -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spi: Initialize cs_gpio and cs_gpios with -ENOENT
The return value from of_get_named_gpio is -ENOENT when the given index matches a hole in the "cs-gpios" property phandle list. However, the default value of cs_gpio in struct spi_device and entries of cs_gpios in struct spi_master is -EINVAL, which is documented to indicate that a GPIO line should not be used for the given spi_device. This sets the default value of cs_gpio in struct spi_device and entries of cs_gpios in struct spi_master to -ENOENT. Thus, -ENOENT is the only value used to indicate that no GPIO line should be used. Signed-off-by: Andreas Larsson --- To be applied to spi/next drivers/spi/spi.c |4 ++-- include/linux/spi/spi.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 4bca50c..b730a50 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -334,7 +334,7 @@ struct spi_device *spi_alloc_device(struct spi_master *master) spi->dev.parent = >dev; spi->dev.bus = _bus_type; spi->dev.release = spidev_release; - spi->cs_gpio = -EINVAL; + spi->cs_gpio = -ENOENT; device_initialize(>dev); return spi; } @@ -1083,7 +1083,7 @@ static int of_spi_register_master(struct spi_master *master) return -ENOMEM; for (i = 0; i < master->num_chipselect; i++) - cs[i] = -EINVAL; + cs[i] = -ENOENT; for (i = 0; i < nb; i++) cs[i] = of_get_named_gpio(np, "cs-gpios", i); diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 30e9c50..b0ae8b8 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -57,7 +57,7 @@ extern struct bus_type spi_bus_type; * @modalias: Name of the driver to use with this device, or an alias * for that name. This appears in the sysfs "modalias" attribute * for driver coldplugging, and in uevents used for hotplugging - * @cs_gpio: gpio number of the chipselect line (optional, -EINVAL when + * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when * when not using a GPIO line) * * A @spi_device is used to interchange data between an SPI slave @@ -261,7 +261,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * queue so the subsystem notifies the driver that it may relax the * hardware by issuing this call * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS - * number. Any individual value may be -EINVAL for CS lines that + * number. Any individual value may be -ENOENT for CS lines that * are not GPIOs (driven by the SPI controller itself). * * Each SPI master controller can communicate with one or more @spi_device -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iio: adc: add exynos5 adc driver under iio framwork
Please ignore the unfinished previous mail.
On 13 February 2013 08:18, Naveen Krishna Ch wrote:
> On 13 February 2013 02:37, Guenter Roeck wrote:
>> On Wed, Jan 23, 2013 at 04:58:06AM -, Naveen Krishna Chatradhi wrote:
>>> This patch add an ADC IP found on EXYNOS5 series socs from Samsung.
>>> Also adds the Documentation for device tree bindings.
>>>
>>> Signed-off-by: Naveen Krishna Chatradhi
>>>
>>> ---
>>> Changes since v1:
>>>
>>> 1. Fixed comments from Lars
>>> 2. Added support for ADC on EXYNOS5410
>>>
>>> Changes since v2:
>>>
>>> 1. Changed the instance name for (struct iio_dev *) to indio_dev
>>> 2. Changed devm_request_irq to request_irq
>>>
>>> Few doubts regarding the mappings and child device handling.
>>> Kindly, suggest me better methods.
>>>
>>> .../bindings/arm/samsung/exynos5-adc.txt | 37 ++
>>> drivers/iio/adc/Kconfig|7 +
>>> drivers/iio/adc/Makefile |1 +
>>> drivers/iio/adc/exynos5_adc.c | 464
>>>
>>> 4 files changed, 509 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>>> create mode 100644 drivers/iio/adc/exynos5_adc.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>>> b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>>> new file mode 100644
>>> index 000..9a5b515
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>>> @@ -0,0 +1,37 @@
>>> +Samsung Exynos5 Analog to Digital Converter bindings
>>> +
>>> +Required properties:
>>> +- compatible:Must be "samsung,exynos5250-adc" for
>>> exynos5250 controllers.
>>> +- reg: Contains ADC register address range (base
>>> address and
>>> + length).
>>> +- interrupts:Contains the interrupt information for the
>>> timer. The
>>> + format is being dependent on which interrupt
>>> controller
>>> + the Samsung device uses.
>>> +
>>> +Note: child nodes can be added for auto probing from device tree.
>>> +
>>> +Example: adding device info in dtsi file
>>> +
>>> +adc@12D1 {
>>> + compatible = "samsung,exynos5250-adc";
>>> + reg = <0x12D1 0x100>;
>>> + interrupts = <0 106 0>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +};
>>> +
>>> +
>>> +Example: Adding child nodes in dts file
>>> +
>>> +adc@12D1 {
>>> +
>>> + /* NTC thermistor is a hwmon device */
>>> + ncp15wb473@0 {
>>> + compatible = "ntc,ncp15wb473";
>>> + reg = <0x0>;
>>> + pullup-uV = <180>;
>>> + pullup-ohm = <47000>;
>>> + pulldown-ohm = <0>;
>>> + };
>>> +};
>>
>> How about:
>>
>> adc: adc@12D1 {
>> compatible = "samsung,exynos5250-adc";
>> reg = <0x12D1 0x100>;
>> interrupts = <0 106 0>;
>> #io-channel-cells = <1>;
>> };
>>
>> ...
>>
>> ncp15wb473@0 {
>> compatible = "ntc,ncp15wb473";
>> reg = <0x0>; /* is this needed ? */
>> io-channels = < 0>;
>> io-channel-names = "adc";
>> pullup-uV = <180>; /* uV or uv ? */
>> pullup-ohm = <47000>;
>> pulldown-ohm = <0>;
>> };
>>
>> The ncp15wb473 driver would then use either iio_channel_get_all() to get the
>> iio
>> channel list or, if it only supports one adc channel per instance,
>> iio_channel_get().
>>
>> In that context, it would probably make sense to rework the ntc_thermistor
>> driver to support both DT as well as direct instantiation using access
>> functions
>> and platform data (as it does today).
>>
>> Also see https://patchwork.kernel.org/patch/2112171/.
Hello Guenter,
I've rebase my adc driver on top of your (OF for IIO patch)
My setup is like the below one. kindly, help me find the right device
tree node params
One ADC controller with 8 channels,
4 NTC thermistors are connected to channel 3, 4, 5 and 6 of ADC respectively
ADC ch - 0
ADC ch - 1
ADC ch - 2
ADC ch - 3 --NTC
ADC ch - 4 --NTC
ADC ch - 5 --NTC
ADC ch - 6 --NTC
ADC ch - 7
I've started off with something like this.
adc0: adc@12D1 {
compatible = "samsung,exynos5250-adc";
reg = <0x12D1 0x100>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
};
adc0: adc@12D1 {
vdd-supply = <_reg>;
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
io-channels = < 3>;
io-channel-names = "adc3";
pullup-uV = <180>;
[PATCH 1/2] regmap: irq: Add support for interrupt type
Most of the MFD module have the GPIO and gpio interrupt is
enabled/disabled through the rising/falling edge type. There
is no specific mask enable/disable registers for GPIO submodules.
Extend the regmap irq to support the irq_set_type() so that
gpio submodule of MFD devices can use the regmap-irq framework
for their interrupt registration.
Signed-off-by: Laxman Dewangan
---
drivers/base/regmap/regmap-irq.c | 97 ++
include/linux/regmap.h | 15 ++
2 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 4706c63..e7a1a26 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -39,8 +39,11 @@ struct regmap_irq_chip_data {
unsigned int *mask_buf;
unsigned int *mask_buf_def;
unsigned int *wake_buf;
+ unsigned int *type_buf;
+ unsigned int *type_buf_def;
unsigned int irq_reg_stride;
+ unsigned int type_reg_stride;
};
static inline const
@@ -107,6 +110,22 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
}
}
+ for (i = 0; i < d->chip->num_type_reg; i++) {
+ if (!d->type_buf_def[i])
+ continue;
+ reg = d->chip->type_base +
+ (i * map->reg_stride * d->type_reg_stride);
+ if (d->chip->type_invert)
+ ret = regmap_update_bits(d->map, reg,
+ d->type_buf_def[i], ~d->type_buf[i]);
+ else
+ ret = regmap_update_bits(d->map, reg,
+ d->type_buf_def[i], d->type_buf[i]);
+ if (ret != 0)
+ dev_err(d->map->dev, "Failed to sync type in %x\n",
+ reg);
+ }
+
if (d->chip->runtime_pm)
pm_runtime_put(map->dev);
@@ -141,6 +160,38 @@ static void regmap_irq_disable(struct irq_data *data)
d->mask_buf[irq_data->reg_offset / map->reg_stride] |= irq_data->mask;
}
+static int regmap_irq_set_type(struct irq_data *data, unsigned int type)
+{
+ struct regmap_irq_chip_data *d = irq_data_get_irq_chip_data(data);
+ struct regmap *map = d->map;
+ const struct regmap_irq *irq_data = irq_to_regmap_irq(d, data->hwirq);
+ int reg = irq_data->type_reg_offset / map->reg_stride;
+
+ if (!(irq_data->type_rising_mask | irq_data->type_falling_mask))
+ return 0;
+
+ d->type_buf[reg] &= ~(irq_data->type_falling_mask |
+ irq_data->type_rising_mask);
+ switch (type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ d->type_buf[reg] |= irq_data->type_falling_mask;
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ d->type_buf[reg] |= irq_data->type_rising_mask;
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ d->type_buf[reg] |= (irq_data->type_falling_mask |
+ irq_data->type_rising_mask);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
static int regmap_irq_set_wake(struct irq_data *data, unsigned int on)
{
struct regmap_irq_chip_data *d = irq_data_get_irq_chip_data(data);
@@ -167,6 +218,7 @@ static const struct irq_chip regmap_irq_chip = {
.irq_bus_sync_unlock= regmap_irq_sync_unlock,
.irq_disable= regmap_irq_disable,
.irq_enable = regmap_irq_enable,
+ .irq_set_type = regmap_irq_set_type,
.irq_set_wake = regmap_irq_set_wake,
};
@@ -375,6 +427,18 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
goto err_alloc;
}
+ if (chip->num_type_reg) {
+ d->type_buf_def = kzalloc(sizeof(unsigned int) *
+ chip->num_type_reg, GFP_KERNEL);
+ if (!d->type_buf_def)
+ goto err_alloc;
+
+ d->type_buf = kzalloc(sizeof(unsigned int) * chip->num_type_reg,
+ GFP_KERNEL);
+ if (!d->type_buf)
+ goto err_alloc;
+ }
+
d->irq_chip = regmap_irq_chip;
d->irq_chip.name = chip->name;
d->irq = irq;
@@ -387,6 +451,8 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
else
d->irq_reg_stride = 1;
+ d->type_reg_stride = chip->type_reg_stride ? : 1;
+
if (!map->use_single_rw && map->reg_stride == 1 &&
d->irq_reg_stride == 1) {
d->status_reg_buf = kmalloc(map->format.val_bytes *
@@ -442,6 +508,33 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
}
}
+ if (chip->num_type_reg) {
+
[PATCH 2/2] regmap: irq: do not write mask register if it is not supported
Ignore the mask register write if mask_base is not provided by
regmap irq client. This is useful when regmap irq framework is
used for the MFD's gpio interrupt support. Typically, gpio has
two registers related to interrupt, one is for setting interrupt
edge type like rising and falling which indirectly work as mask
interrupt register and second as interrupt status register. In
this case mask_base is set as 0.
Now when interrupt enabled/disabled, the mask_buf get set/reset as
it keeps the interrupt enable/disable state but need not to be write
into register. When interrupt occurs, it is masked with interrupt mask
to check interrupt is valid or not and accordingly the isr handler
get called.
Signed-off-by: Laxman Dewangan
---
drivers/base/regmap/regmap-irq.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index e7a1a26..dbdd407 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -80,6 +80,9 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
* suppress pointless writes.
*/
for (i = 0; i < d->chip->num_regs; i++) {
+ if (!d->chip->mask_base)
+ goto skip_mask_reg_update;
+
reg = d->chip->mask_base +
(i * map->reg_stride * d->irq_reg_stride);
if (d->chip->mask_invert)
@@ -92,6 +95,7 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
dev_err(d->map->dev, "Failed to sync masks in %x\n",
reg);
+skip_mask_reg_update:
reg = d->chip->wake_base +
(i * map->reg_stride * d->irq_reg_stride);
if (d->wake_buf) {
@@ -470,6 +474,9 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
/* Mask all the interrupts by default */
for (i = 0; i < chip->num_regs; i++) {
d->mask_buf[i] = d->mask_buf_def[i];
+ if (!chip->mask_base)
+ continue;
+
reg = chip->mask_base +
(i * map->reg_stride * d->irq_reg_stride);
if (chip->mask_invert)
--
1.7.1.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] mtd: davinci_nand: Use managed resources
On Thu, 2013-02-07 at 16:03 +0530, Mrugesh Katepallewar wrote: > davinci_nand driver currently uses normal kzalloc, ioremap and get_clk > routines. This patch replaces these routines with devm_kzalloc, > devm_request_and_ioremap and devm_clk_get resp. > > Signed-off-by: Mrugesh Katepallewar Pushed to l2-mtd.git, thanks! P.S. you could also kill the unneeded duplicated labels, but this is not a big deal. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu
On Tuesday, February 12, 2013 07:59:54 AM Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 08:36:17PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 11, 2013 05:13:30 PM Nathan Zimmer wrote:
> > > There are some spots that I need to give a much deeper review,
> > > cpufreq_register_driver for example.
> > >
> > > But I believe
> > > > @@ -196,7 +195,7 @@ static void __cpufreq_cpu_put(struct cpufreq_policy
> > > > *data, bool sysfs)
> > > > {
> > > > if (!sysfs)
> > > > kobject_put(>kobj);
> > > > - module_put(cpufreq_driver->owner);
> > > > + module_put(rcu_dereference(cpufreq_driver)->owner);
> > > > }
> > > would be ok. In the documentation whatisRCU.txt they give a very similar
> > > example.
> >
> > Well, the very same document states the following:
> >
> > Note that the value returned by rcu_dereference() is valid
> > only within the enclosing RCU read-side critical section.
>
> Ah, there is a code sample in that document showing a bug. I added
> comments to the code sample making it clear even to someone skimming
> the document that the code is buggy.
>
> Thanx, Paul
>
>
> rcu: Make bugginess of code sample more evident
>
> One of the code samples in whatisRCU.txt shows a bug, but someone scanning
> the document quickly might mistake it for a valid use of RCU. Add some
> screaming comments to help keep speed-readers on track.
>
> Reported-by: Nathan Zimmer
> Signed-off-by: Paul E. McKenney
Acked-by: Rafael J. Wysocki
> diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
> index 0cc7820..10df0b8 100644
> --- a/Documentation/RCU/whatisRCU.txt
> +++ b/Documentation/RCU/whatisRCU.txt
> @@ -265,9 +265,9 @@ rcu_dereference()
> rcu_read_lock();
> p = rcu_dereference(head.next);
> rcu_read_unlock();
> - x = p->address;
> + x = p->address; /* BUG!!! */
> rcu_read_lock();
> - y = p->data;
> + y = p->data;/* BUG!!! */
> rcu_read_unlock();
>
> Holding a reference from one RCU read-side critical section
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, Feb 13, 2013 at 2:56 PM, Mimi Zohar wrote:
> On Wed, 2013-02-13 at 14:31 +0200, Kasatkin, Dmitry wrote:
>> On Mon, Feb 11, 2013 at 10:11 PM, Vivek Goyal wrote:
>
>> > @@ -158,7 +165,8 @@ int ima_appraise_measurement(int func, struct
>> > integrity_iint_cache *iint,
>> > }
>> > switch (xattr_value->type) {
>> > case IMA_XATTR_DIGEST:
>> > - if (iint->flags & IMA_DIGSIG_REQUIRED) {
>> > + if (iint->flags & IMA_DIGSIG_REQUIRED ||
>> > + iint->flags & IMA_DIGSIG_OPTIONAL) {
>> > cause = "IMA signature required";
>> > status = INTEGRITY_FAIL;
>> > break;
>>
>> This looks a bit odd... If "optional" signature is missing - we fail..
>> It is optional... Why we should fail?
>
> 'imasig_optional' does not only mean that the signature is optional, but
> also implies that it has to be a digital signature, not a hash. This
> latter part is what IMA_DIGSIG_REQUIRED means.
>
> If 'imasig_optional' set both 'IMA_DIGSIG_OPTIONAL' and
> 'IMA_DIGSIG_REQUIRED', then this change wouldn't be necessary.
>
> IMA_DIGSIG_REQUIRED would enforce that it is a signature.
> IMA_DIGSIG_OPTIONAL would fail only for files with invalid signatures.
>
It sounds odd that optional signature is actually required.
Optional for me means that it may be there or may be not.
If it is not there, then it may be hash or nothing.
I see it is more logical if it is "appraise_type=optional",
which means that we might have no xattr value, hash or signature.
It if happens to be a signature, then IMA_DIGSIG flag will be set.
I asked Vivek to send a policy file he uses in his system.
I would like to see how system configured as a whole...
- Dmitry
> thanks,
>
> Mimi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Update][PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
From: Rafael J. Wysocki
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
---
This includes fixes for two issues spotted by Yasuaki Ishimatsu.
Thanks,
Rafael
---
drivers/acpi/acpi_memhotplug.c | 56 +++---
drivers/acpi/container.c | 12 --
drivers/acpi/dock.c| 19 --
drivers/acpi/processor_driver.c| 24 +---
drivers/acpi/scan.c| 69 +
drivers/pci/hotplug/acpiphp_glue.c |6 +++
drivers/pci/hotplug/sgi_hotplug.c |5 ++
include/acpi/acpi_bus.h|3 +
8 files changed, 139 insertions(+), 55 deletions(-)
Index: test/drivers/acpi/scan.c
===
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -42,6 +42,18 @@ struct acpi_device_bus_id{
struct list_head node;
};
+void acpi_scan_lock_acquire(void)
+{
+ mutex_lock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
+
+void acpi_scan_lock_release(void)
+{
+ mutex_unlock(_scan_lock);
+}
+EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
+
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
{
if (!handler || !handler->attach)
@@ -95,8 +107,6 @@ acpi_device_modalias_show(struct device
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
-static void __acpi_bus_trim(struct acpi_device *start);
-
/**
* acpi_bus_hot_remove_device: hot-remove a device and its children
* @context: struct acpi_eject_event pointer (freed in this func)
@@ -107,7 +117,7 @@ static void __acpi_bus_trim(struct acpi_
*/
void acpi_bus_hot_remove_device(void *context)
{
- struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
+ struct acpi_eject_event *ej_event = context;
struct acpi_device *device = ej_event->device;
acpi_handle handle = device->handle;
acpi_handle temp;
@@ -118,11 +128,19 @@ void acpi_bus_hot_remove_device(void *co
mutex_lock(_scan_lock);
+ /* If there is no handle, the device node has been unregistered. */
+ if (!device->handle) {
+ dev_dbg(>dev, "ACPI handle missing\n");
+ put_device(>dev);
+ goto out;
+ }
+
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(>dev)));
- __acpi_bus_trim(device);
- /* Device node has been released. */
+ acpi_bus_trim(device);
+ /* Device node has
Re: [PATCH 2/3] nbd: fsync and kill block device on shutdown
Il 12/02/2013 22:41, Andrew Morton ha scritto: >> > There are two problems with shutdown in the NBD driver. The first is >> > that receiving the NBD_DISCONNECT ioctl does not sync the filesystem; >> > this is useful because BLKFLSBUF is restricted to processes that have >> > CAP_SYS_ADMIN, and the NBD client may not possess it (fsync of the >> > block device does not sync the filesystem, either). > hm, this says that the lack of a sync is "useful". I think you mean > that the patch-which-adds-the-sync is the thing which is useful, yes? Yes. >> > The second is that once we clear the socket we have no guarantee that >> > later reads will come from the same backing storage. Thus the page cache >> > must be cleaned, lest reads that hit on the page cache will return stale >> > data from the previously-accessible disk. > That sounds like a problem. > >> > Example: >> > >> > # qemu-nbd -r -c/dev/nbd0 /dev/sr0 >> > # file -s /dev/nbd0 >> > /dev/stdin: # UDF filesystem data (version 1.5) etc. >> > # qemu-nbd -d /dev/nbd0 >> > # qemu-nbd -r -c/dev/nbd0 /dev/sda >> > # file -s /dev/nbd0 >> > /dev/stdin: # UDF filesystem data (version 1.5) etc. >> > >> > While /dev/sda has: >> > >> > # file -s /dev/sda >> > /dev/sda: x86 boot sector; etc. > OK, we've described the problems but there's no description here of how > the patch addresses those problems. > > How does this look? Perfect, thanks very much. I tried to similarly balance the "why" and "how" in the new commit message for patch 1. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI / hotplug: Fix concurrency issues and memory leaks
On Wednesday, February 13, 2013 12:31:05 PM Yasuaki Ishimatsu wrote:
> Hi Rafael,
>
> I have another comment at container.c.
>
> 2013/02/13 12:08, Yasuaki Ishimatsu wrote:
> > Hi Rafael,
> >
> > The patch seems good.
> > There is a comment below.
> >
> > 2013/02/13 9:19, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki
> >>
> >> This changeset is aimed at fixing a few different but related
> >> problems in the ACPI hotplug infrastructure.
> >>
> >> First of all, since notify handlers may be run in parallel with
> >> acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
> >> and some of them are installed for ACPI handles that have no struct
> >> acpi_device objects attached (i.e. before those objects are created),
> >> those notify handlers have to take acpi_scan_lock to prevent races
> >> from taking place (e.g. a struct acpi_device is found to be present
> >> for the given ACPI handle, but right after that it is removed by
> >> acpi_bus_trim() running in parallel to the given notify handler).
> >> Moreover, since some of them call acpi_bus_scan() and
> >> acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
> >> should be acquired by the callers of these two funtions rather by
> >> these functions themselves.
> >>
> >> For these reasons, make all notify handlers that can handle device
> >> addition and eject events take acpi_scan_lock and remove the
> >> acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
> >> Accordingly, update all of their users to make sure that they
> >> are always called under acpi_scan_lock.
> >>
> >> Furthermore, since eject operations are carried out asynchronously
> >> with respect to the notify events that trigger them, with the help
> >> of acpi_bus_hot_remove_device(), even if notify handlers take the
> >> ACPI scan lock, it still is possible that, for example,
> >> acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
> >> the notify handler that scheduled its execution and that
> >> acpi_bus_trim() will remove the device node passed to
> >> acpi_bus_hot_remove_device() for ejection. In that case, the struct
> >> acpi_device object obtained by acpi_bus_hot_remove_device() will be
> >> invalid and not-so-funny things will ensue. To protect agaist that,
> >> make the users of acpi_bus_hot_remove_device() run get_device() on
> >> ACPI device node objects that are about to be passed to it and make
> >> acpi_bus_hot_remove_device() run put_device() on them and check if
> >> their ACPI handles are not NULL (make acpi_device_unregister() clear
> >> the device nodes' ACPI handles for that check to work).
> >>
> >> Finally, observe that acpi_os_hotplug_execute() actually can fail,
> >> in which case its caller ought to free memory allocated for the
> >> context object to prevent leaks from happening. It also needs to
> >> run put_device() on the device node that it ran get_device() on
> >> previously in that case. Modify the code accordingly.
> >>
> >> Signed-off-by: Rafael J. Wysocki
> >> ---
> >>
> >> On top of linux-pm.git/linux-next.
> >>
> >> Thanks,
> >> Rafael
> >>
> >> ---
> >> drivers/acpi/acpi_memhotplug.c | 56 +++---
> >> drivers/acpi/container.c | 10 +++--
> >> drivers/acpi/dock.c| 19 --
> >> drivers/acpi/processor_driver.c| 24 +---
> >> drivers/acpi/scan.c| 69
> >> +
> >> drivers/pci/hotplug/acpiphp_glue.c |6 +++
> >> drivers/pci/hotplug/sgi_hotplug.c |5 ++
> >> include/acpi/acpi_bus.h|3 +
> >> 8 files changed, 138 insertions(+), 54 deletions(-)
> >>
> >> Index: test/drivers/acpi/scan.c
> >> ===
> >> --- test.orig/drivers/acpi/scan.c
> >> +++ test/drivers/acpi/scan.c
> >> @@ -42,6 +42,18 @@ struct acpi_device_bus_id{
> >> struct list_head node;
> >> };
> >>
> >> +void acpi_scan_lock_acquire(void)
> >> +{
> >> +mutex_lock(_scan_lock);
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
> >> +
> >> +void acpi_scan_lock_release(void)
> >> +{
> >> +mutex_unlock(_scan_lock);
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
> >> +
> >> int acpi_scan_add_handler(struct acpi_scan_handler *handler)
> >> {
> >> if (!handler || !handler->attach)
> >> @@ -95,8 +107,6 @@ acpi_device_modalias_show(struct device
> >> }
> >> static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
> >>
> >> -static void __acpi_bus_trim(struct acpi_device *start);
> >> -
> >> /**
> >>* acpi_bus_hot_remove_device: hot-remove a device and its children
> >>* @context: struct acpi_eject_event pointer (freed in this func)
> >> @@ -107,7 +117,7 @@ static void __acpi_bus_trim(struct acpi_
> >>*/
> >> void acpi_bus_hot_remove_device(void *context)
> >> {
> >> -struct acpi_eject_event *ej_event = (struct acpi_eject_event *)
> >>
Re: [PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
On Tuesday, February 12, 2013 05:55:26 PM Yinghai Lu wrote: > On Tue, Feb 12, 2013 at 4:19 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > This changeset is aimed at fixing a few different but related > > problems in the ACPI hotplug infrastructure. > > > > First of all, since notify handlers may be run in parallel with > > acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device() > > and some of them are installed for ACPI handles that have no struct > > acpi_device objects attached (i.e. before those objects are created), > > those notify handlers have to take acpi_scan_lock to prevent races > > from taking place (e.g. a struct acpi_device is found to be present > > for the given ACPI handle, but right after that it is removed by > > acpi_bus_trim() running in parallel to the given notify handler). > > Moreover, since some of them call acpi_bus_scan() and > > acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock > > should be acquired by the callers of these two funtions rather by > > these functions themselves. > > > > For these reasons, make all notify handlers that can handle device > > addition and eject events take acpi_scan_lock and remove the > > acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim(). > > Accordingly, update all of their users to make sure that they > > are always called under acpi_scan_lock. > > > > Furthermore, since eject operations are carried out asynchronously > > with respect to the notify events that trigger them, with the help > > of acpi_bus_hot_remove_device(), even if notify handlers take the > > ACPI scan lock, it still is possible that, for example, > > acpi_bus_trim() will run between acpi_bus_hot_remove_device() and > > the notify handler that scheduled its execution and that > > acpi_bus_trim() will remove the device node passed to > > acpi_bus_hot_remove_device() for ejection. In that case, the struct > > acpi_device object obtained by acpi_bus_hot_remove_device() will be > > invalid and not-so-funny things will ensue. To protect agaist that, > > make the users of acpi_bus_hot_remove_device() run get_device() on > > ACPI device node objects that are about to be passed to it and make > > acpi_bus_hot_remove_device() run put_device() on them and check if > > their ACPI handles are not NULL (make acpi_device_unregister() clear > > the device nodes' ACPI handles for that check to work). > > > > Finally, observe that acpi_os_hotplug_execute() actually can fail, > > in which case its caller ought to free memory allocated for the > > context object to prevent leaks from happening. It also needs to > > run put_device() on the device node that it ran get_device() on > > previously in that case. Modify the code accordingly. > > > > Signed-off-by: Rafael J. Wysocki > > Acked-by: Yinghai Lu Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] nbd: support FLUSH requests
Il 13/02/2013 01:03, Alex Bligh ha scritto: >> > Obviously the changelog was inadequate. Please send along a new one >> > which fully describes the reasons for this change. > To be clear I have no complaints about the rest of the patch being > merged. Supporting FLUSH but not FUA is far better than supporting > neither. I just didn't understand dropping FUA given the semantics > of nbd is in essence 'linux bios over tcp'. Not really bios, since it expects FLUSH requests to include no I/O, but yes the semantics of NBD (and virtio-blk) are quite close to those of the Linux block layer. But as far as I can test with free servers, the FUA bits have no advantage over flush. Also, I wasn't sure if SEND_FUA without SEND_FLUSH is valid, and if so how to handle this combination (treat it as writethrough and add FUA to all requests? warn and do nothing?). Andrew, here is a better commit message: 8< --- From: Alex Bligh Subject: nbd: support FLUSH requests Currently, the NBD device does not accept flush requests from the Linux block layer. If the NBD server opened the target with neither O_SYNC nor O_DSYNC, however, the device will be effectively backed by a writeback cache. Without issuing flushes properly, operation of the NBD device will not be safe against power losses. The NBD protocol has support for both a cache flush command and a FUA command flag; the server will also pass a flag to note its support for these features. This patch adds support for the cache flush command and flag. In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl, and map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush. When the flag is active the block layer will send REQ_FLUSH requests, which we translate to NBD_CMD_FLUSH commands. FUA support is not included in this patch because all free software servers implement it with a full fdatasync; thus it has no advantage over supporting flush only. Because I [Paolo] cannot really benchmark it in a realistic scenario, I cannot tell if it is a good idea or not. It is also not clear if it is valid for an NBD server to support FUA but not flush. The Linux block layer gives a warning for this combination, the NBD protocol documentation says nothing about it. The patch also fixes a small problem in the handling of flags: nbd->flags must be cleared at the end of NBD_DO_IT, but the driver was not doing that. The bug manifests itself as follows. Suppose you two different client/server pairs to start the NBD device. Suppose also that the first client supports NBD_SET_FLAGS, and the first server sends NBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two things. Before this patch, the second invocation of NBD_DO_IT will use a stale value of nbd->flags, and the second server will issue an error every time it receives an NBD_CMD_FLUSH command. This bug is pre-existing, but it becomes much more important after this patch; flush failures make the device pretty much unusable, unlike discard failures. Signed-off-by: Alex Bligh Signed-off-by: Paolo Bonzini Cc: Paul Clements Signed-off-by: Andrew Morton --- Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: tps51632: Use regulator_[get|set]_voltage_sel_regmap
On Wed, Feb 13, 2013 at 05:01:09PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] regulator: as3711: Fix checking if no platform initialization data
On Wed, Feb 13, 2013 at 09:34:48AM +0800, Axel Lin wrote: > To skip registering regulator if no platform initialization data, > we should check reg_data rather than ri->desc.name. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3 4/7] memcg: remove memcg from the reclaim iterators
On Wed 13-02-13 11:34:59, Michal Hocko wrote:
> On Tue 12-02-13 12:37:41, Johannes Weiner wrote:
> > On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
> [...]
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 727ec39..31bb9b0 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -144,8 +144,13 @@ struct mem_cgroup_stat_cpu {
> > > };
> > >
> > > struct mem_cgroup_reclaim_iter {
> > > - /* last scanned hierarchy member with elevated css ref count */
> > > + /*
> > > + * last scanned hierarchy member. Valid only if last_dead_count
> > > + * matches memcg->dead_count of the hierarchy root group.
> > > + */
> > > struct mem_cgroup *last_visited;
> > > + unsigned int last_dead_count;
> >
> > Since we read and write this without a lock, I would feel more
> > comfortable if this were a full word, i.e. unsigned long. That
> > guarantees we don't see any partial states.
>
> OK. Changed. Although I though that int is read/modified atomically as
> well if it is aligned to its size.
Ohh, I guess what was your concern. If last_dead_count was int then it
would fit into the same full word slot with generation and so the
parallel read-modify-update cycle could be an issue.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
On Wed, 2013-02-13 at 14:31 +0200, Kasatkin, Dmitry wrote:
> On Mon, Feb 11, 2013 at 10:11 PM, Vivek Goyal wrote:
> > @@ -158,7 +165,8 @@ int ima_appraise_measurement(int func, struct
> > integrity_iint_cache *iint,
> > }
> > switch (xattr_value->type) {
> > case IMA_XATTR_DIGEST:
> > - if (iint->flags & IMA_DIGSIG_REQUIRED) {
> > + if (iint->flags & IMA_DIGSIG_REQUIRED ||
> > + iint->flags & IMA_DIGSIG_OPTIONAL) {
> > cause = "IMA signature required";
> > status = INTEGRITY_FAIL;
> > break;
>
> This looks a bit odd... If "optional" signature is missing - we fail..
> It is optional... Why we should fail?
'imasig_optional' does not only mean that the signature is optional, but
also implies that it has to be a digital signature, not a hash. This
latter part is what IMA_DIGSIG_REQUIRED means.
If 'imasig_optional' set both 'IMA_DIGSIG_OPTIONAL' and
'IMA_DIGSIG_REQUIRED', then this change wouldn't be necessary.
IMA_DIGSIG_REQUIRED would enforce that it is a signature.
IMA_DIGSIG_OPTIONAL would fail only for files with invalid signatures.
thanks,
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: linux-next: manual merge of the ia64 tree with Linus' tree
On Wed, 2013-02-13 at 13:05 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the ia64 tree got a conflict in
> drivers/firmware/efivars.c between commit 83e68189745a ("efi: Make
> 'efi_enabled' a function to query EFI facilities") from the tree and
> commit a93bc0c6e07e ("efi_pstore: Introducing workqueue updating sysfs")
> from the ia64 tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks Stephen, this is all correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / PCI: Initialize PCI root drivers after PCI bus enumeration
On Tuesday, February 12, 2013 05:54:08 PM Yinghai Lu wrote: > On Tue, Feb 12, 2013 at 4:16 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > After commit 1aeae82 (ACPI / PCI: avoid building pci_slot as module) > > the pci_slot driver's .add() callback routine, acpi_pci_slot_add(), > > is executed from within acpi_pci_root_add() before the PCI devices on > > the bus are enumerated and that triggers the WARN_ON() in > > kobject_get(): > > > > WARNING: at /scratch/rafael/work/test/include/linux/kref.h:42 > > kobject_get+0x33/0x40() > > Hardware name: PORTEGE R500 > > Modules linked in: > > Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc7+ #160 > > Call Trace: > > [] warn_slowpath_common+0x7a/0xb0 > > [] warn_slowpath_null+0x15/0x20 > > [] kobject_get+0x33/0x40 > > [] get_device+0x12/0x30 > > [] register_slot+0x243/0x295 > > [] ? trace_hardirqs_on+0xd/0x10 > > [] acpi_ns_walk_namespace+0x10f/0x24a > > [] ? walk_p2p_bridge+0x13b/0x13b > > [] ? walk_p2p_bridge+0x13b/0x13b > > [] acpi_walk_namespace+0xe9/0x132 > > [] ? walk_p2p_bridge+0x13b/0x13b > > [] walk_p2p_bridge+0xf8/0x13b > > [] ? acpi_os_signal_semaphore+0x76/0x87 > > [] ? walk_p2p_bridge+0x13b/0x13b > > [] acpi_ns_walk_namespace+0x10f/0x24a > > [] ? do_sta_before_sun+0x2b/0x2b > > [] ? do_sta_before_sun+0x2b/0x2b > > [] acpi_walk_namespace+0xe9/0x132 > > [] ? acpi_pci_root_add+0x3e7/0x49a > > [] acpi_pci_slot_add+0xb2/0x103 > > [] ? walk_p2p_bridge+0x13b/0x13b > > [] acpi_pci_root_add+0x3ff/0x49a > > > > which means that pci_bus->dev used in register_slot() has not been > > registered yet at that point. > > > > To fix this use the observation that before commit 1aeae82 > > acpi_pci_slot_add() was always run after pci_bus_add_devices() > > and that happened to the acpiphp's .add() callback routine too. > > Thus it is safe to reorder acpi_pci_root_add() to make the PCI root > > drivers' .add() callbacks be run after pci_bus_add_devices(), so do > > that. > > > > This approach was previously proposed by Myron Stowe. > > > > References: https://patchwork.kernel.org/patch/1848781/ > > Signed-off-by: Rafael J. Wysocki > > --- > > > > The commit mentioned in the changelog above is in linux-pm.git/linux-next. > > > > Thanks, > > Rafael > > > > --- > > drivers/acpi/pci_root.c | 13 - > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > Index: test/drivers/acpi/pci_root.c > > === > > --- test.orig/drivers/acpi/pci_root.c > > +++ test/drivers/acpi/pci_root.c > > @@ -600,17 +600,20 @@ static int acpi_pci_root_add(struct acpi > > if (system_state != SYSTEM_BOOTING) > > pci_assign_unassigned_bus_resources(root->bus); > > > > + /* need to after hot-added ioapic is registered */ > > + if (system_state != SYSTEM_BOOTING) > > + pci_enable_bridges(root->bus); > > + > > + pci_bus_add_devices(root->bus); > > + > > mutex_lock(_pci_root_lock); > > + > > list_for_each_entry(driver, _pci_drivers, node) > > if (driver->add) > > driver->add(root); > > - mutex_unlock(_pci_root_lock); > > > > - /* need to after hot-added ioapic is registered */ > > - if (system_state != SYSTEM_BOOTING) > > - pci_enable_bridges(root->bus); > > + mutex_unlock(_pci_root_lock); > > > > - pci_bus_add_devices(root->bus); > > return 1; > > > > out_del_root: > > > > No, we don't need this after > > | commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 > | PCI: Put pci_dev in device tree as early as possible > > in pci/next. > > So we can move that Jiang's patch from your tree to Bjorn's tree? OK, I'm dropping that patch from my tree, then (hopefully, no one has merged my acpi-cleanup branch yet). Bjorn, could you pick up https://patchwork.kernel.org/patch/2003771/ please? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: s5m8767: Fix dev argument for devm_kzalloc and of_get_regulator_init_data
On Wed, Feb 13, 2013 at 09:29:45AM +0800, Axel Lin wrote: > Use >dev rather than iodev->dev for devm_kzalloc() and > of_get_regulator_init_data(), this fixes memory leak. Applied both, thanks. signature.asc Description: Digital signature
Re: [PATCH v2] gpio: mcp23s08: convert driver to DT
On Wed, Feb 13, 2013 at 12:13 PM, Lars Poeschel wrote: > On Monday 11 February 2013 at 22:25:51, Grant Likely wrote: >> >> However, is the pullup selection per-gpio line? If so, then why not >> encode it into the flags field of the gpio specifier? > > Yes, the pullup is per-gpio line. I am working on that. It turns out, that > this is a bit difficult for me, as there is no real documentation and no > other driver is doing it or something similar yet. Exception are very few > gpio soc drivers where situation is a bit different. They seem to rely an > fixed global gpio numbers and they are always memory mapped. > But as I said I am working on it... Part of your problem is that pull-up is pin control territory. We invented that subsystem for a reason, and that reason was that the GPIO subsystem had a hard time accomodating things like this. If you look in drivers/pinctrl/pinctrl-abx500.c which is my latest submitted pinctrl driver you can see that this is basically a quite simple GPIO chip, we just model it as a pin controller with a GPIO front-end too exactly because it can do things like multiplexing, pull-up and pull-down. Have you considered this approach? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: tps51632: Use regulator_[get|set]_voltage_sel_regmap
On Wednesday 13 February 2013 02:31 PM, Axel Lin wrote: Signed-off-by: Axel Lin --- LGTM, Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 vringh 2/2] caif_virtio: Introduce caif over virtio
Hi Rusty,
On Wed, Feb 13, 2013 at 11:16 AM, Rusty Russell wrote:
> Sjur BRENDELAND writes:
>>> > +static inline void ctx_prep_iov(struct cfv_napi_context *ctx)
>>> > +{
>>> > + if (ctx->riov.allocated) {
>>> > + kfree(ctx->riov.iov);
>>> > + ctx->riov.iov = NULL;
>>> > + ctx->riov.allocated = false;
>>> > + }
>>> > + ctx->riov.iov = NULL;
>>> > + ctx->riov.i = 0;
>>> > + ctx->riov.max = 0;
>>> > +}
>>>
>>> Hmm, we should probably make sure you don't have to do this: that if
>>> allocated once, you can simply reuse it by setting i = 0.
>>
>> Yes, I had problems getting the alloc/free of iov right. This is
>> perhaps the least intuitively part of the API. I maybe it's just me, but
>> I think some more helper functions and support from vringh in this
>> area would be great.
>
> Yes, I've neatened my git tree, an in particular added a commit which
> covers this explicitly, and one for the -EPROTO when we get unexpected
> r/w bufs. I've appended them below.
Great, thanks. This helps a lot. I picked up your patch-sett yesterday
so my V2 patch-set is using this already.
...
> +static inline void vringh_iov_init(struct vringh_iov *iov,
> + struct iovec *iovec, unsigned num)
> +{
> + iov->used = iov->i = 0;
> + iov->off = 0;
> + iov->max_num = num;
> + iov->iov = iovec;
> +}
How about supporting struct vringh_kiov and struct kvec as well?
I currently get the following complaints with my V2 patch-set:
drivers/net/caif/caif_virtio.c:486:2: warning: passing argument 1 of
‘vringh_iov_init’ from incompatible pointer type [enabled by default]
...
Thanks,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
> -Original Message- > From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of > Yinghai Lu > Sent: Tuesday, February 12, 2013 11:43 PM > To: KY Srinivasan > Cc: H. Peter Anvin; mi...@kernel.org; linux-kernel@vger.kernel.org; > t...@linutronix.de; h...@linux.intel.com; linux-tip-comm...@vger.kernel.org > Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as special > hypervisor interrupts > > On Tue, Feb 12, 2013 at 7:58 PM, KY Srinivasan wrote: > > > > > >> -Original Message- > >> From: H. Peter Anvin [mailto:h...@zytor.com] > >> Sent: Tuesday, February 12, 2013 10:55 PM > >> To: KY Srinivasan > >> Cc: Yinghai Lu; mi...@kernel.org; linux-kernel@vger.kernel.org; > >> t...@linutronix.de; h...@linux.intel.com; linux-tip-comm...@vger.kernel.org > >> Subject: Re: [tip:x86/hyperv] X86: Handle Hyper-V vmbus interrupts as > >> special > >> hypervisor interrupts > >> > >> On 02/12/2013 07:49 PM, KY Srinivasan wrote: > >> >>> > >> >>> The issue was that you could turn on CONFIG_HYPERV without enabling > >> >>> CONFIG_X86_LOCAL_APIC. Peter fixed it. > >> >>> > >> >> > >> >> He is asking why you are using IS_ENABLED() instead of #ifdef. The > >> >> difference is that IS_ENABLED() works even for modules. > >> > > >> > My mistake! > >> > > >> > >> Well, which one do you need? > > > > I chose the IS_ENABLED() because I wanted to cover the case where HYPERV is > configured as a module as well. > > > > ok, so when HYPERV is built as module, actually it is partially module > as it put some code built-in already? > if user never load hyperv, those code will never not be used. > > Can those code not be put in module _init function? Some code in mshyperv.c is built into the kernel. Registering an IDT entry is dependent on HYPERV drivers being configured - either as modules or built-in. K. Y > > Thanks > > Yinghai > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] mtd: devices: elm: Low power transition support
On Wed, Feb 13, 2013 at 11:42:01AM +, Philip, Avinash wrote:
> On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
> > On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> > > +static int elm_suspend(struct device *dev)
> > > +{
> > > + struct elm_info *info = dev_get_drvdata(dev);
> > > + wait_queue_head_t wq;
> > > + DECLARE_WAITQUEUE(wait, current);
> > > +
> > > + init_waitqueue_head();
> > > + while (1) {
> > > + /* Make sure that ELM not running */
> > > + if (info->idle) {
> > > + add_wait_queue(, );
> > > + schedule();
> > > + remove_wait_queue(, );
> > > + } else {
> > > + break;
> > > + }
> > > + }
> >
> > The above code looks really wrong - it will just spin endlessly with the
> > waitqueues doing nothing useful. What are you trying to do here?
>
> The intention of waitqeue is to make the suspend process really wait till
> the ELM module finishes current activity. Although this type of protection
> already achieved in mtd layer using nand_suspend(), this one is particularly
> required for ELM module to really make sure that *any pending* corrections to
> finish really before gone to suspend.
I don't think you understand what's going on with the above, and why the
above is completely ineffective.
1. Your wait queue head is declared on stack, and there's no references
to it outside of this function. So _nothing_ can activate the wait
queue.
2. You're not changing the current thread's status away from TASK_RUNNING,
so schedule() will either return immediately or it will schedule another
task if it's time for this one to be preempted.
In other words, the above can be rewritten as:
while (info->idle)
schedule();
and it will still have the same effect.
Now, if you want to be kinder to the system, then you should use a
wait queue properly. Put the waitqueue head in struct elm_info. Use
wait_event() here. And call wake_up() where you set info->idle to
false.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: SELinux + ubifs: possible circular locking dependency
On Fri, 2013-02-08 at 15:10 +0100, Marc Kleine-Budde wrote:
> Hello,
>
> I'm on a arm imx28 v3.8-rc6 (+ a handfull of patches to support the
> custom board) but no modifications on ubifs, selinux or the vfs layer.
> And not including the xattr patches by Subodh Nijsure.
>
> When booting with SELinux and lockdep enabled I see this _possible_
> circular locking dependency:
I guess one needs to really understand how lockdep works, because it
seems there is no direct 'tnc_mutex -> isec->lock', and lockdep somehow
deducts this connection inderectly.
However, it seems I see what _may_ be the reason, and here is a patch
which I think may fix the issue. Would you please test/review it? It is
inlined and also attached.
>From a2b29a190227959bdeadf8d412745003c86857ef Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy
Date: Wed, 13 Feb 2013 13:49:14 +0200
Subject: [PATCH] selinux: do not confuse lockdep
Selinux initializes all per-inode 'isec->lock' mutexes in one single place,
which makes lockdep believe they all belong to the same class, which will make
lockdep treat all 'isec->lock' mutexes equivalent. This leads to a lockdep
false-positive reported by Marc Kleine-Budde (see at the
end).
Frankly, I failed to understand the warning and this fix is more of a guess of
what would be the root-cause. I would appreciate if someone could explain me
what this warning actually tells, because I cannot see any 'c->tnc_mutex ->
isec->lock' chain in the code! Where this chain comes from:
">tnc_mutex --> >s_type->i_mutex_key#2 --> >lock"
The lockdep complaint:
Look at the stacktrace #4: here we have 'debugfs_create_dir()'
[5.390312] ==
[5.396500] [ INFO: possible circular locking dependency detected ]
[5.402781] 3.8.0-rc6-5-g4f7e39d #49 Not tainted
[5.407750] ---
[5.414031] systemd/1 is trying to acquire lock:
[5.418656] (>tnc_mutex){+.+...}, at: []
ubifs_tnc_locate+0x30/0x198
[5.426343]
[5.426343] but task is already holding lock:
[5.432218] (>lock){+.+.+.}, at: []
inode_doinit_with_dentry+0x8c/0x55c
[5.440375]
[5.440375] which lock already depends on the new lock.
[5.440375]
[5.448593]
[5.448593] the existing dependency chain (in reverse order) is:
[5.456093]
-> #4 (>lock){+.+.+.}:
[5.460250][] lock_acquire+0x64/0x78
[5.465437][] mutex_lock_nested+0x5c/0x2ec
[5.471125][] inode_doinit_with_dentry+0x8c/0x55c
[5.477437][] security_d_instantiate+0x1c/0x34
[5.483500][] debugfs_mknod.part.15.constprop.18+0x94/0x128
[5.490656][] __create_file+0x1b0/0x25c
[5.496093][] debugfs_create_dir+0x1c/0x28
[5.501781][] pinctrl_init+0x1c/0xd0
[5.506968][] do_one_initcall+0x108/0x17c
[5.512593][] kernel_init_freeable+0xec/0x1b4
[5.518562][] kernel_init+0x8/0xe4
[5.523562][] ret_from_fork+0x14/0x2c
[5.528812]
-> #3 (>s_type->i_mutex_key#2){+.+.+.}:
[5.534312][] lock_acquire+0x64/0x78
[5.539468][] mutex_lock_nested+0x5c/0x2ec
[5.545187][] __create_file+0x50/0x25c
[5.550531][] debugfs_create_dir+0x1c/0x28
[5.556218][] clk_debug_create_subtree+0x1c/0x108
[5.562500][] clk_debug_init+0x68/0xc0
[5.567875][] do_one_initcall+0x108/0x17c
[5.573468][] kernel_init_freeable+0xec/0x1b4
[5.579437][] kernel_init+0x8/0xe4
[5.584437][] ret_from_fork+0x14/0x2c
[5.589687]
-> #2 (prepare_lock){+.+.+.}:
[5.593937][] lock_acquire+0x64/0x78
[5.599125][] mutex_lock_nested+0x5c/0x2ec
[5.604812][] clk_prepare+0x18/0x38
[5.609906][] __gpmi_enable_clk+0x30/0xb0
[5.615531][] gpmi_begin+0x18/0x530
[5.620625][] gpmi_select_chip+0x3c/0x54
[5.626156][] nand_do_read_ops+0x7c/0x3e4
[5.631750][] nand_read+0x50/0x74
[5.636656][] part_read+0x5c/0xa4
[5.641593][] mtd_read+0x84/0xb8
[5.646406][] ubi_io_read+0xa0/0x2c0
[5.651593][] ubi_eba_read_leb+0x190/0x424
[5.657281][] ubi_leb_read+0xac/0x120
[5.662562][] ubifs_leb_read+0x28/0x8c
[5.667906][] ubifs_read_node+0x98/0x2a0
[5.673437][] ubifs_read_sb_node+0x54/0x78
[5.679125][] ubifs_read_superblock+0xc60/0x163c
[5.685343][] ubifs_mount+0x800/0x171c
[5.690687][] mount_fs+0x44/0x184
[5.695593][] vfs_kern_mount+0x4c/0xc0
[5.700968][] do_mount+0x18c/0x8d0
[5.705968][] sys_mount+0x84/0xb8
[5.710875][] mount_block_root+0x118/0x258
[5.716562][] prepare_namespace+0x8c/0x17c
[5.722281][] kernel_init+0x8/0xe4
[5.727281][] ret_from_fork+0x14/0x2c
[5.732531]
-> #1 (>mutex){..}:
[
