Re: mod filenames != modnames? (inconsistent name changing)
Linda Walsh writes:
> Should we have any expectation that a module name and it's filename
> should be equivalent?
>
> I was writing an auto-complete script for modprobe so it wouldn't give
> me the option to double load a module (I'd have to manually type it in if
> I really wanted it).
>
> Trouble is some modules with names w/underscores ('_') change
> register their names with a 'dash'.
But modprobe kvm_intel already works. Just convert any - to _?
> Would it be too much trouble to ask that the same names be used in
> both places?
Well, you could get kernel developers to rename their files with
underscores. I've CC'd them.
We use _ because we turn the module names into identifiers; it's also
the most common choice, and having both is just confusing.
> I have about 30 modules loaded now and out of that list,
> 2 are name changes:
>
> acpi_cpufreq (filename acip-cpufreq.ko)
> kvm_intel (filename kvm-intel.ko)
>
> If I load a bunch more... I find more that change names.
>
> Could the naming in the modules that do this be made consistent?
>
> Not doing so makes automatically tying a mod-name to it's file
> tend toward being non-deterministic.
>
> Many modules use '-' or '_' without being confused.
> It would be helpful if the few confused modules could
> get their identity straight. Is there a problem with
> making these names consistent?
It shouldn't break anything to rename them, if there's consensus I'm
happy to create a patch.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] asymmetric keys: explicitly add the leading zero byte to encoded message
From: Chun-Yi Lee Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a pointer to the _preceding_ byte to RSA_verify() in original code, but it has risk for the byte is not zero because it's not in EM buffer's scope, neither RSA_verify() nor mpi_get_buffer() didn't take care the leading byte. To avoid the risk, that's better we explicitly add the leading zero byte to EM for pass to RSA_verify(). This patch allocate a _EM buffer to capture the result from RSA_I2OSP(), then set the first byte to zero in EM and copy the remaining bytes from _EM. Cc: Rusty Russell Cc: Josh Boyer Cc: Randy Dunlap Cc: Herbert Xu Cc: "David S. Miller" Cc: David Howells Signed-off-by: Chun-Yi Lee --- crypto/asymmetric_keys/rsa.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c index ca1a4f3..7bc99d2 100644 --- a/crypto/asymmetric_keys/rsa.c +++ b/crypto/asymmetric_keys/rsa.c @@ -303,6 +303,7 @@ static int RSA_verify_signature(const struct public_key *key, /* Variables as per RFC3447 sec 8.2.2 */ const u8 *H = sig->digest; u8 *EM = NULL; + u8 *_EM = NULL; MPI m = NULL; size_t k; @@ -337,14 +338,19 @@ static int RSA_verify_signature(const struct public_key *key, /* (2c) Convert the message representative (m) to an encoded message * (EM) of length k octets. * -* NOTE! The leading zero byte is suppressed by MPI, so we pass a -* pointer to the _preceding_ byte to RSA_verify()! +* NOTE! The leading zero byte is suppressed by MPI, so we add it +* back to EM before input to RSA_verify()! */ - ret = RSA_I2OSP(m, k, ); + ret = RSA_I2OSP(m, k, &_EM); if (ret < 0) goto error; - ret = RSA_verify(H, EM - 1, k, sig->digest_size, + EM = kmalloc(k, GFP_KERNEL); + memset(EM, 0, 1); + memcpy(EM + 1, _EM, k-1); + kfree(_EM); + + ret = RSA_verify(H, EM, k, sig->digest_size, RSA_ASN1_templates[sig->pkey_hash_algo].data, RSA_ASN1_templates[sig->pkey_hash_algo].size); -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().
The normal expectation for ERR_PTR() is to put a negative errno into a
pointer. oom_kill puts the magic -1 in the result (and has since
pre-git), which is probably clearer with an explicit cast.
Cc: Andrew Morton
Signed-off-by: Rusty Russell
---
mm/oom_kill.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 79e451a..f9b9cd7 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -288,7 +288,7 @@ enum oom_scan_t oom_scan_process_thread(struct task_struct
*task,
/*
* Simple selection loop. We chose the process with the highest
- * number of 'points'.
+ * number of 'points'. Returns -1 on scan abort.
*
* (not docbooked, we don't want this one cluttering up the manual)
*/
@@ -314,7 +314,7 @@ static struct task_struct *select_bad_process(unsigned int
*ppoints,
continue;
case OOM_SCAN_ABORT:
rcu_read_unlock();
- return ERR_PTR(-1UL);
+ return (void *)(-1UL);
case OOM_SCAN_OK:
break;
};
@@ -657,7 +657,7 @@ void out_of_memory(struct zonelist *zonelist, gfp_t
gfp_mask,
dump_header(NULL, gfp_mask, order, NULL, mpol_mask);
panic("Out of memory and no killable processes...\n");
}
- if (PTR_ERR(p) != -1UL) {
+ if (p != (void *)-1UL) {
oom_kill_process(p, gfp_mask, order, points, totalpages, NULL,
nodemask, "Out of memory");
killed = 1;
--
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/
[PATCH 2/9] PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.
Sweep of the simple cases.
Cc: net...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Julia Lawall
Signed-off-by: Rusty Russell
---
arch/arm/mach-omap2/i2c.c | 2 +-
arch/m68k/amiga/platform.c| 2 +-
arch/m68k/kernel/time.c | 2 +-
arch/m68k/q40/config.c| 2 +-
arch/powerpc/kernel/iommu.c | 2 +-
arch/powerpc/kernel/time.c| 2 +-
arch/powerpc/platforms/ps3/time.c | 2 +-
arch/powerpc/sysdev/rtc_cmos_setup.c | 2 +-
arch/s390/hypfs/hypfs_dbfs.c | 2 +-
drivers/char/tile-srom.c | 2 +-
drivers/infiniband/core/cma.c | 2 +-
drivers/net/appletalk/cops.c | 2 +-
drivers/net/appletalk/ltpc.c | 2 +-
drivers/net/ethernet/amd/atarilance.c | 2 +-
drivers/net/ethernet/amd/mvme147.c| 2 +-
drivers/net/ethernet/amd/ni65.c | 2 +-
drivers/net/ethernet/amd/sun3lance.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c | 2 +-
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 2 +-
drivers/platform/x86/samsung-q10.c| 2 +-
drivers/regulator/fan53555.c | 2 +-
drivers/spi/spi-fsl-spi.c | 2 +-
drivers/spi/spidev.c | 2 +-
drivers/video/omap2/dss/core.c| 2 +-
fs/btrfs/dev-replace.c| 2 +-
fs/btrfs/inode.c | 2 +-
net/bluetooth/hci_sysfs.c | 2 +-
net/bridge/netfilter/ebtable_broute.c | 2 +-
net/bridge/netfilter/ebtable_filter.c | 2 +-
net/bridge/netfilter/ebtable_nat.c| 2 +-
net/ipv4/netfilter/arptable_filter.c | 2 +-
net/ipv4/netfilter/iptable_filter.c | 2 +-
net/ipv4/netfilter/iptable_mangle.c | 2 +-
net/ipv4/netfilter/iptable_nat.c | 2 +-
net/ipv4/netfilter/iptable_raw.c | 2 +-
net/ipv4/netfilter/iptable_security.c | 2 +-
net/ipv6/netfilter/ip6table_filter.c | 2 +-
net/ipv6/netfilter/ip6table_mangle.c | 2 +-
net/ipv6/netfilter/ip6table_nat.c | 2 +-
net/ipv6/netfilter/ip6table_raw.c | 2 +-
net/ipv6/netfilter/ip6table_security.c| 2 +-
scripts/coccinelle/api/ptr_ret.cocci | 10 +-
sound/soc/soc-io.c| 2 +-
43 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index d940e53..b456b44 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -181,7 +181,7 @@ int __init omap_i2c_add_bus(struct
omap_i2c_bus_platform_data *i2c_pdata,
sizeof(struct omap_i2c_bus_platform_data));
WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", name);
- return PTR_RET(pdev);
+ return PTR_ERR_OR_ZERO(pdev);
}
static int __init omap_i2c_cmdline(void)
diff --git a/arch/m68k/amiga/platform.c b/arch/m68k/amiga/platform.c
index 6083088..dacd9f9 100644
--- a/arch/m68k/amiga/platform.c
+++ b/arch/m68k/amiga/platform.c
@@ -56,7 +56,7 @@ static int __init amiga_init_bus(void)
n = AMIGAHW_PRESENT(ZORRO3) ? 4 : 2;
pdev = platform_device_register_simple("amiga-zorro", -1,
zorro_resources, n);
- return PTR_RET(pdev);
+ return PTR_ERR_OR_ZERO(pdev);
}
subsys_initcall(amiga_init_bus);
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index bea6bcf..7eb9792 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -90,7 +90,7 @@ static int __init rtc_init(void)
return -ENODEV;
pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
- return PTR_RET(pdev);
+ return PTR_ERR_OR_ZERO(pdev);
}
module_init(rtc_init);
diff --git a/arch/m68k/q40/config.c b/arch/m68k/q40/config.c
index 658542b..078bb74 100644
--- a/arch/m68k/q40/config.c
+++ b/arch/m68k/q40/config.c
@@ -338,6 +338,6 @@ static __init int q40_add_kbd_device(void)
return -ENODEV;
pdev = platform_device_register_simple("q40kbd", -1, NULL, 0);
- return PTR_RET(pdev);
+ return PTR_ERR_OR_ZERO(pdev);
}
arch_initcall(q40_add_kbd_device);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index c0d0dbd..3a149eb 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -102,7 +102,7 @@ static int __init fail_iommu_debugfs(void)
struct dentry *dir = fault_create_debugfs_attr("fail_iommu",
[PATCH 8/9] x86: remove weird PTR_ERR() in do_debug
62edab905 changed the argument to notify_die() from dr6 to , but weirdly, used PTR_ERR() to cast it to a long. Since dr6 is on the stack, this is an abuse of PTR_ERR(). Cast to long, as per kernel standard. Cc: x...@kernel.org Cc: K.Prasad Signed-off-by: Rusty Russell --- arch/x86/kernel/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 772e2a8..9340dfb 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -437,7 +437,7 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code) /* Store the virtualized DR6 value */ tsk->thread.debugreg6 = dr6; - if (notify_die(DIE_DEBUG, "debug", regs, PTR_ERR(), error_code, + if (notify_die(DIE_DEBUG, "debug", regs, (long), error_code, SIGTRAP) == NOTIFY_STOP) goto exit; -- 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/
[PATCH 7/9] staging/zcache: don't use PTR_RET().
We've already tested that it's an error.
Cc: Dan Magenheimer
Signed-off-by: Rusty Russell
---
drivers/staging/zcache/zcache-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/zcache/zcache-main.c
b/drivers/staging/zcache/zcache-main.c
index dcceed2..88e7fe7 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -1908,7 +1908,7 @@ static int zcache_init(void)
#endif
if (IS_ERR(old_ops) || old_ops) {
if (IS_ERR(old_ops))
- return PTR_RET(old_ops);
+ return PTR_ERR(old_ops);
pr_warn("%s: frontswap_ops overridden\n", namestr);
}
}
--
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/
Re: [PATCH 4/4] KVM: PPC: Add hugepage support for IOMMU in-kernel handling
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> @@ -185,7 +186,31 @@ static unsigned long kvmppc_realmode_gpa_to_hpa(struct
> kvm_vcpu *vcpu,
> unsigned long hva, hpa, pg_size = 0, offset;
> unsigned long gfn = gpa >> PAGE_SHIFT;
> bool writing = gpa & TCE_PCI_WRITE;
> + struct kvmppc_iommu_hugepage *hp;
>
> + /*
> + * Try to find an already used hugepage.
> + * If it is not there, the kvmppc_lookup_pte() will return zero
> + * as it won't do get_page() on a huge page in real mode
> + * and therefore the request will be passed to the virtual mode.
> + */
> + if (tt) {
> + spin_lock(>hugepages_lock);
> + list_for_each_entry(hp, >hugepages, list) {
> + if ((gpa < hp->gpa) || (gpa >= hp->gpa + hp->size))
> + continue;
> +
> + /* Calculate host phys address keeping flags and offset
> in the page */
> + offset = gpa & (hp->size - 1);
> +
> + /* pte_pfn(pte) should return an address aligned to
> pg_size */
> + hpa = (pte_pfn(hp->pte) << PAGE_SHIFT) + offset;
> + spin_unlock(>hugepages_lock);
> +
> + return hpa;
> + }
> + spin_unlock(>hugepages_lock);
> + }
Wow this is run in real mode right ?
spin_lock() and spin_unlock() are a big no-no in real mode. If lockdep
and/or spinlock debugging are enabled and something goes pear-shaped
they are going to bring your whole system down in a blink in quite
horrible ways.
If you are going to do that, you need some kind of custom low-level
lock.
Also, I see that you are basically using a non-ordered list and doing a
linear search in it every time. That's going to COST !
You should really consider a more efficient data structure. You should
also be able to do something that doesn't require locks for readers.
> /* Find a KVM memslot */
> memslot = search_memslots(kvm_memslots(vcpu->kvm), gfn);
> if (!memslot)
> @@ -237,6 +262,10 @@ static long kvmppc_clear_tce_real_mode(struct kvm_vcpu
> *vcpu,
> if (oldtce & TCE_PCI_WRITE)
> SetPageDirty(page);
>
> + /* Do not put a huge page and continue without error */
> + if (PageCompound(page))
> + continue;
> +
> if (realmode_put_page(page)) {
> ret = H_TOO_HARD;
> break;
> @@ -282,7 +311,7 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned
> long liobn,
> if (iommu_tce_put_param_check(tbl, ioba, tce))
> return H_PARAMETER;
>
> - hpa = kvmppc_realmode_gpa_to_hpa(vcpu, tce, true);
> + hpa = kvmppc_realmode_gpa_to_hpa(vcpu, tt, tce, true);
> if (hpa == ERROR_ADDR) {
> vcpu->arch.tce_reason = H_TOO_HARD;
> return H_TOO_HARD;
> @@ -295,6 +324,11 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned
> long liobn,
> if (unlikely(ret)) {
> struct page *pg = realmode_pfn_to_page(hpa);
> BUG_ON(!pg);
> +
> + /* Do not put a huge page and return an error */
> + if (!PageCompound(pg))
> + return H_HARDWARE;
> +
> if (realmode_put_page(pg)) {
> vcpu->arch.tce_reason = H_HARDWARE;
> return H_TOO_HARD;
> @@ -351,7 +385,7 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> vcpu->arch.tce_tmp_num = 0;
> vcpu->arch.tce_reason = 0;
>
> - tces = (unsigned long *) kvmppc_realmode_gpa_to_hpa(vcpu,
> + tces = (unsigned long *) kvmppc_realmode_gpa_to_hpa(vcpu, NULL,
> tce_list, false);
> if ((unsigned long)tces == ERROR_ADDR)
> return H_TOO_HARD;
> @@ -374,7 +408,7 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
>
> /* Translate TCEs and go get_page */
> for (i = 0; i < npages; ++i) {
> - unsigned long hpa = kvmppc_realmode_gpa_to_hpa(vcpu,
> + unsigned long hpa = kvmppc_realmode_gpa_to_hpa(vcpu, tt,
> vcpu->arch.tce_tmp[i], true);
> if (hpa == ERROR_ADDR) {
> vcpu->arch.tce_tmp_num = i;
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] remoteproc: don't use PTR_RET().
We've already tested that it's an error.
Cc: Ohad Ben-Cohen
Cc: Robert Tivy
Signed-off-by: Rusty Russell
---
drivers/remoteproc/da8xx_remoteproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/drivers/remoteproc/da8xx_remoteproc.c
index 9b2e60a..129f7b9 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -165,7 +165,7 @@ static int reset_assert(struct device *dev)
dsp_clk = clk_get(dev, NULL);
if (IS_ERR(dsp_clk)) {
dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
- return PTR_RET(dsp_clk);
+ return PTR_ERR(dsp_clk);
}
davinci_clk_reset_assert(dsp_clk);
--
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/
[PATCH 1/9] PTR_RET is now PTR_ERR_OR_ZERO
True, it's often used in return statements, but after much bikeshedding
it's probably better to have an explicit name.
(I tried just putting the IS_ERR check inside PTR_ERR itself and gcc
usually generated no more code. But that clashes current expectations
of how PTR_ERR behaves, so having a separate function is better).
Suggested-by: Julia Lawall
Suggested-by: "Michael S. Tsirkin"
Cc: Julia Lawall
Cc: "Michael S. Tsirkin"
Signed-off-by: Rusty Russell
---
include/linux/err.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/err.h b/include/linux/err.h
index f2edce2..ee365c4 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -52,7 +52,7 @@ static inline void * __must_check ERR_CAST(const void *ptr)
return (void *) ptr;
}
-static inline int __must_check PTR_RET(const void *ptr)
+static inline int __must_check PTR_ERR_OR_ZERO(const void *ptr)
{
if (IS_ERR(ptr))
return PTR_ERR(ptr);
@@ -60,6 +60,9 @@ static inline int __must_check PTR_RET(const void *ptr)
return 0;
}
+/* Deprecated */
+#define PTR_RET(p) PTR_ERR_OR_ZERO(p)
+
#endif
#endif /* _LINUX_ERR_H */
--
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/
[PATCH 5/9] pinctrl: don't use PTR_RET().
We've already tested that it's an error.
Cc: Sebastian Hesselbarth
Signed-off-by: Rusty Russell
---
drivers/pinctrl/mvebu/pinctrl-dove.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 428ea96..dd7e0a8 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -597,7 +597,7 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
clk = devm_clk_get(>dev, NULL);
if (IS_ERR(clk)) {
dev_err(>dev, "Unable to get pdma clock");
- return PTR_RET(clk);
+ return PTR_ERR(clk);
}
clk_prepare_enable(clk);
--
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/
[PATCH 3/9] s390: Replace weird use of PTR_RET.
Saves repeating "(void __force *)__uptr" but it's less clear. Using
the output of PTR_RET() to determine the error rather than just
testing IS_ERR() is odd.
For example, I *assume* __gptr_to_uptr() never returns NULL? Because
the __ret would be 0 for the old code. The new version is clearer, IMHO:
it would try to get_user() on that address.
If you hate this variant, I can just s/PTR_RET/PTR_ERR_OR_ZERO/ instead.
Cc: Heiko Carstens
Cc: Christian Borntraeger
Cc: Martin Schwidefsky
Signed-off-by: Rusty Russell
---
arch/s390/kvm/gaccess.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/gaccess.h b/arch/s390/kvm/gaccess.h
index 302e0e5..99d789e 100644
--- a/arch/s390/kvm/gaccess.h
+++ b/arch/s390/kvm/gaccess.h
@@ -42,9 +42,11 @@ static inline void __user *__gptr_to_uptr(struct kvm_vcpu
*vcpu,
({ \
__typeof__(gptr) __uptr = __gptr_to_uptr(vcpu, gptr, 1);\
int __mask = sizeof(__typeof__(*(gptr))) - 1; \
- int __ret = PTR_RET((void __force *)__uptr);\
+ int __ret; \
\
- if (!__ret) { \
+ if (IS_ERR((void __force *)__uptr)) { \
+ __ret = PTR_ERR((void __force *)__uptr);\
+ } else {\
BUG_ON((unsigned long)__uptr & __mask); \
__ret = get_user(x, __uptr);\
} \
@@ -55,9 +57,11 @@ static inline void __user *__gptr_to_uptr(struct kvm_vcpu
*vcpu,
({ \
__typeof__(gptr) __uptr = __gptr_to_uptr(vcpu, gptr, 1);\
int __mask = sizeof(__typeof__(*(gptr))) - 1; \
- int __ret = PTR_RET((void __force *)__uptr);\
+ int __ret; \
\
- if (!__ret) { \
+ if (IS_ERR((void __force *)__uptr)) { \
+ __ret = PTR_ERR((void __force *)__uptr);\
+ } else {\
BUG_ON((unsigned long)__uptr & __mask); \
__ret = put_user(x, __uptr);\
} \
--
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/
[PATCH 4/9] acpi: Replace weird use of PTR_RET.
This functions is really weird. It sets rc to -ENOMEM, then overrides
it. It was converted to PTR_RET in a1458187 when it should have
simply been rewritten.
This version makes it more explicit, with a single IS_ERR() test.
Cc: Rafael J. Wysocki
Cc: Alexandru Gheorghiu
Signed-off-by: Rusty Russell
---
drivers/acpi/acpi_pad.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 27bb6a9..46e0b3c 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -231,16 +231,19 @@ static struct task_struct *ps_tsks[NR_CPUS];
static unsigned int ps_tsk_num;
static int create_power_saving_task(void)
{
- int rc = -ENOMEM;
+ int rc;
ps_tsks[ps_tsk_num] = kthread_run(power_saving_thread,
(void *)(unsigned long)ps_tsk_num,
"acpi_pad/%d", ps_tsk_num);
- rc = PTR_RET(ps_tsks[ps_tsk_num]);
- if (!rc)
- ps_tsk_num++;
- else
+
+ if (IS_ERR(ps_tsks[ps_tsk_num])) {
+ rc = PTR_ERR(ps_tsks[ps_tsk_num]);
ps_tsks[ps_tsk_num] = NULL;
+ } else {
+ rc = 0;
+ ps_tsk_num++;
+ }
return rc;
}
--
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/
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
> static pte_t kvmppc_lookup_pte(pgd_t *pgdir, unsigned long hva, bool writing,
> - unsigned long *pte_sizep)
> + unsigned long *pte_sizep, bool do_get_page)
> {
> pte_t *ptep;
> unsigned int shift = 0;
> @@ -135,6 +136,14 @@ static pte_t kvmppc_lookup_pte(pgd_t *pgdir, unsigned
> long hva, bool writing,
> if (!pte_present(*ptep))
> return __pte(0);
>
> + /*
> + * Put huge pages handling to the virtual mode.
> + * The only exception is for TCE list pages which we
> + * do need to call get_page() for.
> + */
> + if ((*pte_sizep > PAGE_SIZE) && do_get_page)
> + return __pte(0);
> +
> /* wait until _PAGE_BUSY is clear then set it atomically */
> __asm__ __volatile__ (
> "1: ldarx %0,0,%3\n"
> @@ -148,6 +157,18 @@ static pte_t kvmppc_lookup_pte(pgd_t *pgdir, unsigned
> long hva, bool writing,
> : "cc");
>
> ret = pte;
> + if (do_get_page && pte_present(pte) && (!writing || pte_write(pte))) {
> + struct page *pg = NULL;
> + pg = realmode_pfn_to_page(pte_pfn(pte));
> + if (realmode_get_page(pg)) {
> + ret = __pte(0);
> + } else {
> + pte = pte_mkyoung(pte);
> + if (writing)
> + pte = pte_mkdirty(pte);
> + }
> + }
> + *ptep = pte;/* clears _PAGE_BUSY */
>
> return ret;
> }
So now you are adding the clearing of _PAGE_BUSY that was missing for
your first patch, except that this is not enough since that means that
in the "emulated" case (ie, !do_get_page) you will in essence return
and then use a PTE that is not locked without any synchronization to
ensure that the underlying page doesn't go away... then you'll
dereference that page.
So either make everything use speculative get_page, or make the emulated
case use the MMU notifier to drop the operation in case of collision.
The former looks easier.
Also, any specific reason why you do:
- Lock the PTE
- get_page()
- Unlock the PTE
Instead of
- Read the PTE
- get_page_unless_zero
- re-check PTE
Like get_user_pages_fast() does ?
The former will be two atomic ops, the latter only one (faster), but
maybe you have a good reason why that can't work...
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] powerpc: Prepare to support kernel handling of IOMMU map/unmap
On Sun, 2013-06-16 at 14:26 +1000, Benjamin Herrenschmidt wrote:
> > +int realmode_get_page(struct page *page)
> > +{
> > + if (PageCompound(page))
> > + return -EAGAIN;
> > +
> > + get_page(page);
> > +
> > + return 0;
> > +}
Shouldn't it be get_page_unless_zero ?
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] powerpc: Prepare to support kernel handling of IOMMU map/unmap
> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_FLATMEM)
> +int realmode_get_page(struct page *page)
> +{
> + if (PageCompound(page))
> + return -EAGAIN;
> +
> + get_page(page);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(realmode_get_page);
> +
> +int realmode_put_page(struct page *page)
> +{
> + if (PageCompound(page))
> + return -EAGAIN;
> +
> + if (!atomic_add_unless(>_count, -1, 1))
> + return -EAGAIN;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(realmode_put_page);
> +#endif
Several worries here, mostly that if the generic code ever changes
(something gets added to get_page() that makes it no-longer safe for use
in real mode for example, or some other condition gets added to
put_page()), we go out of sync and potentially end up with very hard and
very subtle bugs.
It might be worth making sure that:
- This is reviewed by some generic VM people (and make sure they
understand why we need to do that)
- A comment is added to get_page() and put_page() to make sure that if
they are changed in any way, dbl check the impact on our
realmode_get_page() (or "ping" us to make sure things are still ok).
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control
Quoting Paul Walmsley (2013-06-11 02:47:13) > On Tue, 11 Jun 2013, Prashant Gaikwad wrote: > > > Why not implement these APIs in DFLL clock driver itself and pass RST > > address > > register to driver? > > The DFLL DVCO reset registers are CAR registers, not DFLL registers. > Functions that operate on registers in one IP block shouldn't be located > in another IP block's driver. Paul & Co., These patches appear fine to me but I did not see any Acks, nor could I tell if a v2 was necessary based on the comments. Will there be another version? If not an Acked-by or Reviewed-by would be cool. Regards, Mike > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] KVM: PPC: Add support for multiple-TCE hcalls
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> This adds real mode handlers for the H_PUT_TCE_INDIRECT and
> H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO
> devices or emulated PCI. These calls allow adding multiple entries
> (up to 512) into the TCE table in one call which saves time on
> transition to/from real mode.
>
> This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs
> (copied from user and verified) before writing the whole list into
> the TCE table. This cache will be utilized more in the upcoming
> VFIO/IOMMU support to continue TCE list processing in the virtual
> mode in the case if the real mode handler failed for some reason.
>
> This adds a guest physical to host real address converter
> and calls the existing H_PUT_TCE handler. The converting function
> is going to be fully utilized by upcoming VFIO supporting patches.
>
> This also implements the KVM_CAP_PPC_MULTITCE capability,
> so in order to support the functionality of this patch, QEMU
> needs to query for this capability and set the "hcall-multi-tce"
> hypertas property only if the capability is present, otherwise
> there will be serious performance degradation.
>
> Cc: David Gibson
> Signed-off-by: Alexey Kardashevskiy
> Signed-off-by: Paul Mackerras
>
> ---
> Changelog:
> 2013/06/05:
> * fixed mistype about IBMVIO in the commit message
> * updated doc and moved it to another section
> * changed capability number
>
> 2013/05/21:
> * added kvm_vcpu_arch::tce_tmp
> * removed cleanup if put_indirect failed, instead we do not even start
> writing to TCE table if we cannot get TCEs from the user and they are
> invalid
> * kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce
> and kvmppc_emulated_validate_tce (for the previous item)
> * fixed bug with failthrough for H_IPI
> * removed all get_user() from real mode handlers
> * kvmppc_lookup_pte() added (instead of making lookup_linux_pte public)
> ---
> Documentation/virtual/kvm/api.txt | 17 ++
> arch/powerpc/include/asm/kvm_host.h |2 +
> arch/powerpc/include/asm/kvm_ppc.h | 16 +-
> arch/powerpc/kvm/book3s_64_vio.c| 118 ++
> arch/powerpc/kvm/book3s_64_vio_hv.c | 266
> +++
> arch/powerpc/kvm/book3s_hv.c| 39 +
> arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 +
> arch/powerpc/kvm/book3s_pr_papr.c | 37 -
> arch/powerpc/kvm/powerpc.c |3 +
> include/uapi/linux/kvm.h|1 +
> 10 files changed, 473 insertions(+), 32 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 5f91eda..6c082ff 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2362,6 +2362,23 @@ calls by the guest for that service will be passed to
> userspace to be
> handled.
>
>
> +4.83 KVM_CAP_PPC_MULTITCE
> +
> +Capability: KVM_CAP_PPC_MULTITCE
> +Architectures: ppc
> +Type: vm
> +
> +This capability tells the guest that multiple TCE entry add/remove hypercalls
> +handling is supported by the kernel. This significanly accelerates DMA
> +operations for PPC KVM guests.
> +
> +Unlike other capabilities in this section, this one does not have an ioctl.
> +Instead, when the capability is present, the H_PUT_TCE_INDIRECT and
> +H_STUFF_TCE hypercalls are to be handled in the host kernel and not passed to
> +the guest. Othwerwise it might be better for the guest to continue using
> H_PUT_TCE
> +hypercall (if KVM_CAP_SPAPR_TCE or KVM_CAP_SPAPR_TCE_IOMMU are present).
> +
> +
> 5. The kvm_run structure
>
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> index af326cd..85d8f26 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -609,6 +609,8 @@ struct kvm_vcpu_arch {
> spinlock_t tbacct_lock;
> u64 busy_stolen;
> u64 busy_preempt;
> +
> + unsigned long *tce_tmp;/* TCE cache for TCE_PUT_INDIRECT hall */
> #endif
> };
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index a5287fe..e852921b 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -133,8 +133,20 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu
> *vcpu);
>
> extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
> struct kvm_create_spapr_tce *args);
> -extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> - unsigned long ioba, unsigned long tce);
> +extern struct kvmppc_spapr_tce_table *kvmppc_find_tce_table(
> + struct kvm_vcpu *vcpu, unsigned long liobn);
> +extern long kvmppc_emulated_validate_tce(unsigned long tce);
> +extern void kvmppc_emulated_put_tce(struct kvmppc_spapr_tce_table *tt,
> + unsigned long
Gumstix Overo linux-3.10-rc6 Boot
linux-3.10-rc6 Boots on Gumstix Overo. Do you want the .config for a defconfig? 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 kbuild-next] kconfig/lxdialog: Add definitions for mininimum (re)size values
On Sat, Jun 15, 2013 at 11:07:35AM +0200, Sedat Dilek wrote:
> Commit c8dc68ad0fbd ("kconfig/lxdialog: support resize") added support
> for resizing, but forgot to collect all hardcoded values at one single
> place.
>
> Also add a definition for the check for a minimum screen/window size
> of 80x19.
>
> [ ChangeLog v3:
> * Rename MENU_{HEIGTH,WIDTH}_MIN -> MENUBOX_{HEIGTH,WIDTH}_MIN
> ChangeLog v2:
> * Rename WIN_{HEIGTH,WIDTH}_MIN -> WINDOW_{HEIGTH,WIDTH}_MIN
> * Mention the check for a minimum screen/window size in the changelog
> * Add a comment above the block of new definitions ]
>
> Signed-off-by: Sedat Dilek
Acked-by: Wang YanQing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] module: don't modify argument of module_kallsyms_lookup_name()
Mathias Krause writes: > If we pass a pointer to a const string in the form "module:symbol" > module_kallsyms_lookup_name() will try to split the string at the colon, > i.e., will try to modify r/o data. That will, in fact, fail on a kernel > with enabled CONFIG_DEBUG_RODATA. > > Avoid modifying the passed string in module_kallsyms_lookup_name(), > modify find_module_all() instead to pass it the module name length. > > Signed-off-by: Mathias Krause Applied, thanks. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] PTR_ERR: return 0 if ptr isn't an error value.
Julia Lawall writes: > On Thu, 13 Jun 2013, Michael S. Tsirkin wrote: > >> On Thu, Jun 13, 2013 at 02:07:40PM +0930, Rusty Russell wrote: >> > I think using PTR_ERR() is a less bad solution than promoting PTR_RET, >> > which has a non-obvious name. >> >> Will a longer name make the function more obvious? >> PTR_ERR_OR_ZERO() ? >> PTR_ERR0() ? >> PTR_ERR() can then stay simple for cases where we know we >> are on the error path. > > I was thinking of something along those lines. And in that case, PTR_ERR > could stay without the additional test. > julia OK, sold :) Will send out a series now with PTR_ERR_OR_ZERO. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: blackfin: kernel: sprintf(), need avoid NUL for '%s'
i think you mean NULL instead of NUL
that said, the kernel is smart enough to replace NULL with "(null)",
so i don't see much point in this patch
-mike
On Wed, May 29, 2013 at 5:43 AM, Chen Gang wrote:
>
> When it is kernel symbol, the 'modname' will be NUL, and the 'symname'
> contents the valid name.
>
> So for sprintf(), need avoid NUL for '%s'.
>
>
> Signed-off-by: Chen Gang
> ---
> arch/blackfin/kernel/trace.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/blackfin/kernel/trace.c b/arch/blackfin/kernel/trace.c
> index c36efa0..11f98bb 100644
> --- a/arch/blackfin/kernel/trace.c
> +++ b/arch/blackfin/kernel/trace.c
> @@ -51,7 +51,7 @@ void decode_address(char *buf, unsigned long address)
> if (!modname)
> modname = delim = "";
> sprintf(buf, "{ %s%s%s%s + 0x%lx }",
> - delim, modname, delim, symname,
> + delim, modname ? : "kernel", delim, symname,
> (unsigned long)offset);
> return;
> }
> --
> 1.7.7.6
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
A question on RCU vs. preempt-RCU
Hello, guys. Kent recently implemented a generic percpu reference counter. It's scheduled to be merged in the coming merge window and some part of cgroup refcnting is already converted to it. https://git.kernel.org/cgit/linux/kernel/git/tj/percpu.git/tree/include/linux/percpu-refcount.h?h=for-3.11 https://git.kernel.org/cgit/linux/kernel/git/tj/percpu.git/tree/lib/percpu-refcount.c?h=for-3.11 It's essentially a generalized form of module refcnting but uses regular RCU instead of toggling preemption for local atomicity. I've been running some performance tests with different preemption levels and, with CONFIG_PREEMPT, the percpu ref could be slower by around 10% or at the worst contrived case maybe even close to 20% when compared to simple atomic_t on a single CPU (when hit by multiple CPUs concurrently, it of course destroys atomic_t). Most of the slow down seems to come from the preempt tree RCU calls and there no longer seems to be a way to opt out of that RCU implementation when CONFIG_PREEMPT. For most use cases, the trade-off should be fine. With any kind of cross-cpu traffic, which there usually will be, it should be an easy win for the percpu-refcount even when CONFIG_PREEMPT; however, I've been looking to replace the module ref with the generic one and the performance degradation there has low but existing possibility of being noticeable in some edge use cases. We can convert the percpu-refcount to use preempt_disable/enable() paired with call_rcu_sched() but IIUC that would have latency implications from the callback processing side, right? Given that module ref killing would be very low-frequency, it shouldn't contribute significant amount of callbacks but I'd like to avoid providing two separate implementations if at all possible. So, what would be the right thing to do here? How bad would converting percpu-refcount to sched-RCU by default be? Would the extra overhead on module ref be acceptable when CONFIG_PREEMPT? What do you guys think? Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: ths7303: remove unused member driver_data
Hi Laurent, On Sun, Jun 16, 2013 at 5:21 AM, Laurent Pinchart wrote: > Hi Prabhakar, > > Thanks for the patch. > > On Saturday 15 June 2013 22:04:10 Prabhakar Lad wrote: >> From: "Lad, Prabhakar" >> >> This patch removes the driver_data member from ths7303_state structure. >> The driver_data member was intended to differentiate between ths7303 and >> ths7353 chip and get the g_chip_ident, But as of now g_chip_ident is >> obsolete, so there is no need of driver_data. > > What tree it this based on ? linuxtv/master still uses driver_data in the > ths7303_g_chip_ident() function. > Ah forgot to mention this is based on Hans's branch http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/for-v3.11 Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
On 2013/6/16 8:44, Richard Yao wrote: On 06/15/2013 02:22 AM, shencanquan wrote: Hello, Richard and Jeff, we found that llseek has another bug when in SEEK_END. it should be add the inode lock and unlock. this bug can be reproduce the following scenario: on one nodeA, open the file and then write some data to file and close the file . on another nodeB , open the file and llseek the end of file . the position of file is old. Did these operations occur sequentially or did they occur concurrently? If you meant the former, the inode cache is not being invalidated. That should be a bug because Oracle claims OCFS2 is cache-coherent. However, it is possible that this case was left out of the cache-coherence protocol for performance purposes. If that is the case, then this would be by design. someone who works for Oracle would need to comment on that though. it is a occur sequentially. after close the file on NodeA , on nodeB and then open the file and llseek the end of file. If you meant the latter, you should ask yourself what would happen when you run two separate programs on the same file in a local filesystem. There should be no way to avoid a race without some kind of a locking mechanism. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] irqchip: Add support for TI-NSPIRE irqchip
Hi, On 08/06/2013, at 11:58 AM, Daniel Tang wrote: > This patch adds support for the interrupt controllers found in some > TI-Nspire models. > I was wondering if this patch had gone through yet. Was there something else I forgot to fix or needed to add? Cheers, Daniel Tang-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/7] mm/page_alloc: fix blank in show_free_areas
There is a blank in show_free_areas which lead to dump messages aren't
aligned. This patch remove blank.
Before patch:
[155219.720141] active_anon:50675 inactive_anon:35273 isolated_anon:0
[155219.720141] active_file:215421 inactive_file:344268 isolated_file:0
[155219.720141] unevictable:0 dirty:35 writeback:0 unstable:0
[155219.720141] free:1334870 slab_reclaimable:28833 slab_unreclaimable:5115
[155219.720141] mapped:25233 shmem:35511 pagetables:1705 bounce:0
[155219.720141] free_cma:0
After patch:
[ 73.913889] active_anon:39578 inactive_anon:32082 isolated_anon:0
[ 73.913889] active_file:14621 inactive_file:57993 isolated_file:0
[ 73.913889] unevictable:0dirty:263 writeback:0 unstable:0
[ 73.913889] free:1865614 slab_reclaimable:3264 slab_unreclaimable:4566
[ 73.913889] mapped:21192 shmem:32327 pagetables:1572 bounce:0
[ 73.913889] free_cma:0
Signed-off-by: Wanpeng Li
---
mm/page_alloc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 18102e1..e6e881a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3004,12 +3004,12 @@ void show_free_areas(unsigned int filter)
}
printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n"
- " active_file:%lu inactive_file:%lu isolated_file:%lu\n"
- " unevictable:%lu"
- " dirty:%lu writeback:%lu unstable:%lu\n"
- " free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n"
- " mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
- " free_cma:%lu\n",
+ "active_file:%lu inactive_file:%lu isolated_file:%lu\n"
+ "unevictable:%lu"
+ "dirty:%lu writeback:%lu unstable:%lu\n"
+ "free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n"
+ "mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
+ "free_cma:%lu\n",
global_page_state(NR_ACTIVE_ANON),
global_page_state(NR_INACTIVE_ANON),
global_page_state(NR_ISOLATED_ANON),
--
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/
[PATCH v2 7/7] mm/pgtable: Don't accumulate addr during pgd prepopulate pmd
The old codes accumulate addr to get right pmd, however,
currently pmds are preallocated and transfered as a parameter,
there is unnecessary to accumulate addr variable any more, this
patch remove it.
Signed-off-by: Wanpeng Li
---
arch/x86/mm/pgtable.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 17fda6a..cb787da 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -240,7 +240,6 @@ static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t
*pgdp)
static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd, pmd_t
*pmds[])
{
pud_t *pud;
- unsigned long addr;
int i;
if (PREALLOCATED_PMDS == 0) /* Work around gcc-3.4.x bug */
@@ -248,8 +247,7 @@ static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t
*pgd, pmd_t *pmds[])
pud = pud_offset(pgd, 0);
- for (addr = i = 0; i < PREALLOCATED_PMDS;
-i++, pud++, addr += PUD_SIZE) {
+ for (i = 0; i < PREALLOCATED_PMDS; i++, pud++) {
pmd_t *pmd = pmds[i];
if (i >= KERNEL_PGD_BOUNDARY)
--
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/
[PATCH v2 3/7] mm/writeback: commit reason of WB_REASON_FORKER_THREAD mismatch name
After commit 839a8e86("writeback: replace custom worker pool implementation
with unbound workqueue"), there is no bdi forker thread any more. However,
WB_REASON_FORKER_THREAD is still used due to it is somewhat userland visible
and we won't be exposing exactly the same information with just a different
name.
Signed-off-by: Wanpeng Li
---
include/linux/writeback.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 8b5cec4..cf077a7 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -47,6 +47,11 @@ enum wb_reason {
WB_REASON_LAPTOP_TIMER,
WB_REASON_FREE_MORE_MEM,
WB_REASON_FS_FREE_SPACE,
+/*
+ * There is no bdi forker thread any more and works are done by emergency
+ * worker, however, this is somewhat userland visible and we'll be exposing
+ * exactly the same information, so it has a mismatch name.
+ */
WB_REASON_FORKER_THREAD,
WB_REASON_MAX,
--
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/
[PATCH v2 6/7] mm/thp: fix doc for transparent huge zero page
Changelog: v1 - > v2: * add Kirill's Acked Transparent huge zero page is used during the page fault instead of in khugepaged. # ls /sys/kernel/mm/transparent_hugepage/ defrag enabled khugepaged use_zero_page # ls /sys/kernel/mm/transparent_hugepage/khugepaged/ alloc_sleep_millisecs defrag full_scans max_ptes_none pages_collapsed pages_to_scan scan_sleep_millisecs This patch corrects the documentation just like the codes done. Acked-by: Kirill A. Shutemov Signed-off-by: Wanpeng Li --- Documentation/vm/transhuge.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 8785fb8..4a63953 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -120,8 +120,8 @@ By default kernel tries to use huge zero page on read page fault. It's possible to disable huge zero page by writing 0 or enable it back by writing 1: -echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page -echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page +echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page +echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll -- 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/
[PATCH v2 1/7] mm/writeback: remove wb_reason_name
wb_reason_name is not used any more, this patch remove it.
Signed-off-by: Wanpeng Li
---
include/linux/writeback.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index e27468e..8b5cec4 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -51,7 +51,6 @@ enum wb_reason {
WB_REASON_MAX,
};
-extern const char *wb_reason_name[];
/*
* A control structure which tells the writeback code what to do. These are
--
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/
[PATCH v2 2/7] mm/writeback: Don't check force_wait to handle bdi->work_list
After commit 839a8e86("writeback: replace custom worker pool implementation
with unbound workqueue"), bdi_writeback_workfn runs off bdi_writeback->dwork,
on each execution, it processes bdi->work_list and reschedules if there are
more things to do instead of flush any work that race with us existing. It is
unecessary to check force_wait in wb_do_writeback since it is always 0 after
the mentioned commit. This patch remove the force_wait in wb_do_writeback.
Signed-off-by: Wanpeng Li
---
fs/fs-writeback.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index f892dec..e15aa97 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -959,7 +959,7 @@ static long wb_check_old_data_flush(struct bdi_writeback
*wb)
/*
* Retrieve work items and do the writeback they describe
*/
-static long wb_do_writeback(struct bdi_writeback *wb, int force_wait)
+static long wb_do_writeback(struct bdi_writeback *wb)
{
struct backing_dev_info *bdi = wb->bdi;
struct wb_writeback_work *work;
@@ -967,12 +967,6 @@ static long wb_do_writeback(struct bdi_writeback *wb, int
force_wait)
set_bit(BDI_writeback_running, >bdi->state);
while ((work = get_next_work_item(bdi)) != NULL) {
- /*
-* Override sync mode, in case we must wait for completion
-* because this thread is exiting now.
-*/
- if (force_wait)
- work->sync_mode = WB_SYNC_ALL;
trace_writeback_exec(bdi, work);
@@ -1021,7 +1015,7 @@ void bdi_writeback_workfn(struct work_struct *work)
* rescuer as work_list needs to be drained.
*/
do {
- pages_written = wb_do_writeback(wb, 0);
+ pages_written = wb_do_writeback(wb);
trace_writeback_pages_written(pages_written);
} while (!list_empty(>work_list));
} else {
--
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/
[PATCH v2 5/7] mm/page_alloc: fix doc for numa_zonelist_order
The default zonelist order selecter will select "node" order if any node's DMA zone comprises greater than 70% of its local memory instead of 60%, according to default_zonelist_order::low_kmem_size > total * 70/100. Signed-off-by: Wanpeng Li --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index a5717c3..15d341a 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -531,7 +531,7 @@ Specify "[Dd]efault" to request automatic configuration. Autoconfiguration will select "node" order in following case. (1) if the DMA zone does not exist or (2) if the DMA zone comprises greater than 50% of the available memory or -(3) if any node's DMA zone comprises greater than 60% of its local memory and +(3) if any node's DMA zone comprises greater than 70% of its local memory and the amount of local memory is big enough. Otherwise, "zone" order will be selected. Default order is recommended unless -- 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/
[PATCH 2/2] f2fs: optimise the init_dirty_segmap function
From: Namjae Jeon
Optimise the while loop condition
Since this condition will always be true and while loop will
be terminated by the following condition in code:
if (segno >= TOTAL_SEGS(sbi))
break;
Hence we can replace the while loop condition with while(1)
instead of always checking for segno to be less than Total segs.
Also we do not need to use TOTAL_SEGS() everytime. We can store
this value in a local variable since this value is constant.
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
fs/f2fs/segment.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index b15debc..e351222 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1582,13 +1582,13 @@ static void init_dirty_segmap(struct f2fs_sb_info *sbi)
{
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
struct free_segmap_info *free_i = FREE_I(sbi);
- unsigned int segno = 0, offset = 0;
+ unsigned int segno = 0, offset = 0, total_segs = TOTAL_SEGS(sbi);
unsigned short valid_blocks;
- while (segno < TOTAL_SEGS(sbi)) {
+ while (1) {
/* find dirty segment based on free segmap */
- segno = find_next_inuse(free_i, TOTAL_SEGS(sbi), offset);
- if (segno >= TOTAL_SEGS(sbi))
+ segno = find_next_inuse(free_i, total_segs, offset);
+ if (segno >= total_segs)
break;
offset = segno + 1;
valid_blocks = get_valid_blocks(sbi, segno, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs: add remount_fs callback support
From: Namjae Jeon
Add the f2fs_remount function call which will be used
during the filesystem remounting. This function
will help us to change the mount options specific to
f2fs.
Also modify the f2fs background_gc mount option, which
will allow the user to dynamically trun on/off the
garbage collection in f2fs based on the background_gc
value. If background_gc=on, Garbage collection will
be turned off & if background_gc=off, Garbage collection
will be truned on.
By default the garbage collection is on in f2fs.
Change Log:
v2: Incorporated the review comments by Gu Zheng.
Removing the restore part for VFS flags
Updating comments with proper flag conditions
Display GC background option as ON/OFF
Revised conditions to stop GC in case of remount
v1: Initial changes for adding remount_fs callback
support.
Cc: Gu Zheng
Signed-off-by: Namjae Jeon
Signed-off-by: Pankaj Kumar
---
Documentation/filesystems/f2fs.txt |9 +-
fs/f2fs/super.c| 235 +++-
2 files changed, 160 insertions(+), 84 deletions(-)
diff --git a/Documentation/filesystems/f2fs.txt
b/Documentation/filesystems/f2fs.txt
index bd3c56c..b91e2f2 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -98,8 +98,13 @@ Cleaning Overhead
MOUNT OPTIONS
-background_gc_off Turn off cleaning operations, namely garbage collection,
- triggered in background when I/O subsystem is idle.
+background_gc=%s Turn on/off cleaning operations, namely garbage
+ collection, triggered in background when I/O subsystem
is
+ idle. If background_gc=on, it will turn on the garbage
+ collection and if background_gc=off, garbage collection
+ will be truned off.
+ Default value for this option is on. So garbage
+ collection is on by default.
disable_roll_forward Disable the roll-forward recovery routine
discardIssue discard/TRIM commands when a segment is cleaned.
no_heapDisable heap-style segment allocation which finds free
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index ba56549..5a11484 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -34,7 +34,7 @@
static struct kmem_cache *f2fs_inode_cachep;
enum {
- Opt_gc_background_off,
+ Opt_gc_background,
Opt_disable_roll_forward,
Opt_discard,
Opt_noheap,
@@ -46,7 +46,7 @@ enum {
};
static match_table_t f2fs_tokens = {
- {Opt_gc_background_off, "background_gc_off"},
+ {Opt_gc_background, "background_gc=%s"},
{Opt_disable_roll_forward, "disable_roll_forward"},
{Opt_discard, "discard"},
{Opt_noheap, "no_heap"},
@@ -76,6 +76,91 @@ static void init_once(void *foo)
inode_init_once(>vfs_inode);
}
+static int parse_options(struct super_block *sb, char *options)
+{
+ struct f2fs_sb_info *sbi = F2FS_SB(sb);
+ substring_t args[MAX_OPT_ARGS];
+ char *p, *name;
+ int arg = 0;
+
+ if (!options)
+ return 0;
+
+ while ((p = strsep(, ",")) != NULL) {
+ int token;
+ if (!*p)
+ continue;
+ /*
+* Initialize args struct so we know whether arg was
+* found; some options take optional arguments.
+*/
+ args[0].to = args[0].from = NULL;
+ token = match_token(p, f2fs_tokens, args);
+
+ switch (token) {
+ case Opt_gc_background:
+ name = match_strdup([0]);
+
+ if (!name)
+ return -ENOMEM;
+ if (!strncmp(name, "on", 2))
+ set_opt(sbi, BG_GC);
+ else if (!strncmp(name, "off", 3))
+ clear_opt(sbi, BG_GC);
+ else {
+ kfree(name);
+ return -EINVAL;
+ }
+ kfree(name);
+ break;
+ case Opt_disable_roll_forward:
+ set_opt(sbi, DISABLE_ROLL_FORWARD);
+ break;
+ case Opt_discard:
+ set_opt(sbi, DISCARD);
+ break;
+ case Opt_noheap:
+ set_opt(sbi, NOHEAP);
+ break;
+#ifdef CONFIG_F2FS_FS_XATTR
+ case Opt_nouser_xattr:
+ clear_opt(sbi, XATTR_USER);
+ break;
+#else
+ case Opt_nouser_xattr:
+ f2fs_msg(sb, KERN_INFO,
+ "nouser_xattr options not supported");
Re: [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
On 06/15/2013 01:09 AM, Jeff Liu wrote:
> [Add ocfs2-devel to CC-list]
>
> Hello Richard,
>
> Thanks for your patch.
>
> On 06/15/2013 03:23 AM, Richard Yao wrote:
>
>> There are multiple issues with the custom llseek implemented in ocfs2 for
>> implementing SEEK_HOLE/SEEK_DATA.
>>
>> 1. It takes the inode->i_mutex lock before calling generic_file_llseek(),
>> which
>> is unnecessary.
>
> Agree, but please see my comments below.
>
>>
>> 2. It fails to take the filp->f_lock spinlock before modifying filp->f_pos
>> and
>> filp->f_version, which differs from generic_file_llseek().
>>
>> 3. It does a offset > inode->i_sb->s_maxbytes check that permits seeking up
>> to
>> the maximum file size possible on the ocfs2 filesystem, even when it is past
>> the end of the file. Seeking beyond that (if possible), would return EINVAL
>> instead of ENXIO.
>>
>> 4. The switch statement tries to cover all whence values when in reality it
>> should only care about SEEK_HOLE/SEEK_DATA. Any other cases should be passsed
>> to generic_file_llseek().
>
> I have another patch set for refactoring ocfs2_file_llseek() but not yet
> found time
> to run a comprehensive tests. It can solve the existing issues but also
> improved the
> SEEK_DATA/SEEK_HOLE for unwritten extents, i.e. OCFS2_EXT_UNWRITTEN.
>
> With this change, SEEK_DATA/SEEK_HOLE will go into separate function with a
> little code
> duplication instead of the current mix-ups in ocfs2_seek_data_hole_offset(),
> i.e,
>
> loff_t ocfs2_file_llseek()
> {
> switch (origin) {
> case SEEK_END:
> case SEEK_CUR:
> case SEEK_SET:
> return generic_file_llseek(file, offset, origin);
> case SEEK_DATA:
> return ocfs2_seek_data(file, offset);
> case SEEK_HOLE:
> return ocfs2_seek_hole(file, offset);
> default:
> return -EINVAL;
> }
> }
>
> I personally like keeping SEEK_DATA/SEEK_HOLE in switch...case style rather
> than dealing with them in a condition check block.
I would prefer to see the code structured like this:
loff_t ocfs2_file_llseek()
{
switch (origin) {
case SEEK_DATA:
return ocfs2_seek_data(file, offset);
case SEEK_HOLE:
return ocfs2_seek_hole(file, offset);
default:
return generic_file_llseek(file, offset, origin);
}
}
Unfortunately, I just noticed that this code has a problem. In specific,
generic_file_llseek() calls generic_file_llseek_size(), which has a
switch statement for whence that fails to distinguish between SEEK_SET
and invalid whence values. Invalid whence values are mapped to SEEK_SET
instead of returning EINVAL, which is wrong. That issue affects all
filesystems that do not specify a custom llseek() function and it would
affect ocfs2 if my version of the function is used.
signature.asc
Description: OpenPGP digital signature
Re: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
On 06/15/2013 02:22 AM, shencanquan wrote: > Hello, Richard and Jeff, >we found that llseek has another bug when in SEEK_END. it should be > add the inode lock and unlock. >this bug can be reproduce the following scenario: >on one nodeA, open the file and then write some data to file and > close the file . >on another nodeB , open the file and llseek the end of file . the > position of file is old. Did these operations occur sequentially or did they occur concurrently? If you meant the former, the inode cache is not being invalidated. That should be a bug because Oracle claims OCFS2 is cache-coherent. However, it is possible that this case was left out of the cache-coherence protocol for performance purposes. If that is the case, then this would be by design. someone who works for Oracle would need to comment on that though. If you meant the latter, you should ask yourself what would happen when you run two separate programs on the same file in a local filesystem. There should be no way to avoid a race without some kind of a locking mechanism. signature.asc Description: OpenPGP digital signature
RE: [PATCH v15 0/4] trace,x86: irq vector tracepoint support
> > This patchset breaks building with SGI UV support enabled: > > /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c: In function > ‘uv_bau_init’: > /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c:2130:1: error: > ‘trace_uv_bau_message_intr1’ undeclared (first > use in this function) > /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c:2130:1: note: > each undeclared identifier is reported only once > for each function it appears in I will fix it. Thanks. Seiji
Re: [RFC] pinctrl: generic: Add DT bindings
On Sun, Jun 16, 2013 at 1:52 AM, Laurent Pinchart wrote: > Hi Linus, > On Sunday 16 June 2013 01:51:32 Linus Walleij wrote: >> As dicussed earlier this was designed for systems where >> you could set the pull-up resistance, like >> >> bias-pull-up = <60>; >> >> would give 600kOhm pull up. >> >> In most existing systems that is silly, as they can't specify it, so they >> should be able to do just: >> >> bias-pull-up; >> >> as that is all they can do. If we have to cut one way, we should cut the >> former until such a system appears. > > I'm fine with bias-pull-up = <1>; vs bias-pull-up;. What bothers me a bit is > bias-pull-up = <0>; vs bias-disable;. Oh yeah OK you got a point there for sure. Setting bias-pull-up = <0>; would be equal to short-circuit so it does not make any kind of sense. Let's keep an eye on this. 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: PPC440GX (taishan config) compilation errors
Sorry, it is a toolchain bug. Instead of using the one from ELDK,
now I used the
http://download.ronetix.info/toolchains/powerpc/powerpc-eabi-4.3.3.tar.bz2
and everything went smoothly. Thanks.
On Sat, Jun 15, 2013 at 3:14 PM, Peter Teoh wrote:
>
> Compiling the latest linus-git image for PPC440GX (taishan config) I
> got the following errors:
>
> git describe
> v3.10-rc5-219-ga2648eb
>
> Issuing "make V=1 ARCH=powerpc CROSS_COMPILE=ppc_4xx- oldconfig" where
> the config file ".config" is from powerpc/configs/44x gives:
>
> make -f scripts/Makefile.build obj=net/wireless
> make -f scripts/Makefile.build obj=lib
> make -f scripts/Makefile.build obj=lib/zlib_inflate
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> mkdir -p arch/powerpc/boot/
> ppc_4xx-gcc -m32 -Wp,-MD,arch/powerpc/boot/.treeboot-currituck.o.d
> -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> -Os -msoft-float -pipe -fomit-frame-pointer -fno-builtin -fPIC
> -nostdinc -isystem
> /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include
> -fno-stack-protector -Iarch/powerpc/boot
>
> -I/media/d4fdcf1c-c7f1-419a-8418-3d0e7b1ad883/linux_latest/arch/powerpc/boot
> -mcpu=405 -c -o arch/powerpc/boot/treeboot-currituck.o
> arch/powerpc/boot/treeboot-currituck.c
> {standard input}: Assembler messages:
> {standard input}:82: Error: Unrecognized opcode: `mfdcrx'
> make[1]: *** [arch/powerpc/boot/treeboot-currituck.o] Error 1
> make: *** [uImage] Error 2
>
> Question:
>
> a. why is the "mkdir -p arch/powerpc/boot/" repeated so many times?
> b. what is the cause of error "mfdcrx"?
>
> Any idea what is the cause of error?
>
>
> --
> Regards,
> Peter Teoh
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: generic: Add DT bindings
Hi Linus, On Sunday 16 June 2013 01:51:32 Linus Walleij wrote: > On Sun, Jun 16, 2013 at 1:35 AM, Laurent Pinchart wrote: > > On Saturday 15 June 2013 22:16:13 Heiko Stübner wrote: > >> Am Samstag, 15. Juni 2013, 21:56:05 schrieb Linus Walleij: > >> > >> Disable would the be either > >> > >> bias-disable; > >> > >> or > >> > >> bias-pull-up = <0>; > >> > >> A driver should probably handle both, as both are valid pinconf options > >> or this. > > > > I feel a bit uneasy about that. Do we really need to support two different > > ways to achieve the same result ? > > In this specific case I think yes, but not on all options. > > As dicussed earlier this was designed for systems where > you could set the pull-up resistance, like > > bias-pull-up = <60>; > > would give 600kOhm pull up. > > In most existing systems that is silly, as they can't specify it, so they > should be able to do just: > > bias-pull-up; > > as that is all they can do. If we have to cut one way, we should cut the > former until such a system appears. I'm fine with bias-pull-up = <1>; vs bias-pull-up;. What bothers me a bit is bias-pull-up = <0>; vs bias-disable;. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: ths7303: remove unused member driver_data
Hi Prabhakar,
Thanks for the patch.
On Saturday 15 June 2013 22:04:10 Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> This patch removes the driver_data member from ths7303_state structure.
> The driver_data member was intended to differentiate between ths7303 and
> ths7353 chip and get the g_chip_ident, But as of now g_chip_ident is
> obsolete, so there is no need of driver_data.
What tree it this based on ? linuxtv/master still uses driver_data in the
ths7303_g_chip_ident() function.
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/i2c/ths7303.c |4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
> index 2e17abc..0a2dacb 100644
> --- a/drivers/media/i2c/ths7303.c
> +++ b/drivers/media/i2c/ths7303.c
> @@ -38,7 +38,6 @@ struct ths7303_state {
> struct v4l2_bt_timings bt;
> int std_id;
> int stream_on;
> - int driver_data;
> };
>
> enum ths7303_filter_mode {
> @@ -355,9 +354,6 @@ static int ths7303_probe(struct i2c_client *client,
> sd = >sd;
> v4l2_i2c_subdev_init(sd, client, _ops);
>
> - /* store the driver data to differntiate the chip */
> - state->driver_data = (int)id->driver_data;
> -
> /* set to default 480I_576I filter mode */
> if (ths7303_setval(sd, THS7303_FILTER_MODE_480I_576I) < 0) {
> v4l_err(client, "Setting to 480I_576I filter mode failed!\n");
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pinctrl: generic: Add DT bindings
On Sun, Jun 16, 2013 at 1:35 AM, Laurent Pinchart wrote: > On Saturday 15 June 2013 22:16:13 Heiko Stübner wrote: >> Am Samstag, 15. Juni 2013, 21:56:05 schrieb Linus Walleij: >> Disable would the be either >> bias-disable; >> or >> bias-pull-up = <0>; >> >> A driver should probably handle both, as both are valid pinconf options or >> this. > > I feel a bit uneasy about that. Do we really need to support two different > ways to achieve the same result ? In this specific case I think yes, but not on all options. As dicussed earlier this was designed for systems where you could set the pull-up resistance, like bias-pull-up = <60>; would give 600kOhm pull up. In most existing systems that is silly, as they can't specify it, so they should be able to do just: bias-pull-up; as that is all they can do. If we have to cut one way, we should cut the former until such a system appears. 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: [RFC] pinctrl: generic: Add DT bindings
Hi Heiko,
On Saturday 15 June 2013 22:16:13 Heiko Stübner wrote:
> Am Samstag, 15. Juni 2013, 21:56:05 schrieb Linus Walleij:
> > On Fri, Jun 14, 2013 at 12:39 AM, Laurent Pinchart wrote:
> > > mmcif_pins: mmcif {
> > > mux {
> > > renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
> > > renesas,function = "mmc0";
> > > };
> > > cfg {
> > > renesas,groups = "mmc0_data8_0";
> > > renesas,pins = "PORT279";
> > > bias-pull-up = <1>;
> >
> > If I understood your code correctly that last statement can *optionally*
> >
> > be written like just:
> > bias-pull-up;
> >
> > Without the parameter?
> >
> > I think that Heiko's implementation does this anyway.
>
> Yep, with the fixes-series from yesterday the bias-pull-* now have a better
> default value of <1>.
>
> so you can do
> bias-pull-up;
> which is then identical to the
> bias-pull-up = <1>;
> above (both are valid of course).
My patch used bias-pull-up = <1>; as the current version of Heiko's DT parser
didn't support bias-pull-up; correctly at that time. It's fixed now, and my
prefered is then bias-pull-up;.
> Disable would the be either
> bias-disable;
> or
> bias-pull-up = <0>;
>
> A driver should probably handle both, as both are valid pinconf options or
> this.
I feel a bit uneasy about that. Do we really need to support two different
ways to achieve the same result ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] arm: Remove sa1111 special case from mm setup code
I don't think this special case is needed anymore. From what I can tell, setup_dma_zone() takes care of marking the region to be reserved for DMA, and that happens before arm_memblock_init() which calls arm_mm_memblock_reserve(). Therefore the mm setup should already know about the reserved region and it won't need to be explicitly reserved and then freed. That means the special case can be dropped from the common code. Signed-off-by: Grant Likely --- Hi Russell and Nicolas, I really don't know if this is correct. The MM code is not my strong area. Please take a look. Thanks, g. arch/arm/mm/init.c | 5 - arch/arm/mm/mmu.c | 8 2 files changed, 13 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 9a5cdc0..73212fe 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -598,11 +598,6 @@ void __init mem_init(void) totalram_pages += free_all_bootmem(); -#ifdef CONFIG_SA - /* now that our DMA memory is actually so designated, we can free it */ - free_reserved_area(__va(PHYS_PFN_OFFSET), swapper_pg_dir, 0, NULL); -#endif - free_highpages(); reserved_pages = free_pages = 0; diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index e0d8565..f281a24 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -1147,14 +1147,6 @@ void __init arm_mm_memblock_reserve(void) * and can only be in node 0. */ memblock_reserve(__pa(swapper_pg_dir), SWAPPER_PG_DIR_SIZE); - -#ifdef CONFIG_SA - /* -* Because of the SA DMA bug, we want to preserve our -* precious DMA-able memory... -*/ - memblock_reserve(PHYS_OFFSET, __pa(swapper_pg_dir) - PHYS_OFFSET); -#endif } /* -- 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/
Re: [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
On Wed, Jun 12, 2013 at 1:31 PM, Scott Wood wrote: > > I'm not sure it's stable material if this is something that has never > worked... > > The device tree binding will also need to be fixed to note the difference in > "reg" between "fsl,gianfar-mdio" and "fsl-gianfar-tbi" -- and should give an > example of the latter. I don't remember how much I tested it, but I'm pretty sure that at some of the suspect devices did work for me. My goal was to maintain compatibility with existing device trees, and just refactor the code so that it's easier to read. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Sat, Jun 15, 2013 at 10:22 PM, Linus Walleij wrote: > On Sat, Jun 15, 2013 at 11:19 PM, Linus Walleij > wrote: >> It still works like a charm on the Integrator/AP. >> Tested-by: Linus Walleij > > BTW here is the new hwirq output in /proc/interrupts and it's really nice: > > root@integrator:/proc cat interrupts >CPU0 > 17: 1845 pic 1 uart-pl010 > 22: 13716 pic 6 timer > 24: 0 pic 8 rtc-pl030 > Err: 0 Glad you like it. :-) g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [BUGFIX v2 2/4] ACPI, DOCK: resolve possible deadlock scenarios
On Saturday, June 15, 2013 11:20:40 PM Rafael J. Wysocki wrote: > On Saturday, June 15, 2013 10:17:42 PM Rafael J. Wysocki wrote: [...] > > Which sysfs interfaces do you mean, by the way? > > If you mean "eject", then it takes acpi_scan_lock and hotplug_dock_devices() > should always be run under acpi_scan_lock too. It isn't at the moment, > because write_undock() doesn't take acpi_scan_lock(), but this is an obvious > bug (so I'm going to send a patch to fix it in a while). > > With that bug fixed, the possible race between acpi_eject_store() and > hotplug_dock_devices() should be prevented from happening, so perhaps we're > worrying about something that cannot happen? So here's a question: What particular races are possible if we remove ds->hp_lock entirely without doing anything else just yet? I mean, how to *trigger* them from the start to the end and not how they can possibly happen but never do, because there's no way they can be actually triggered? 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 v15 0/4] trace,x86: irq vector tracepoint support
On 06/14/2013 08:47 AM, Seiji Aguchi wrote: > Any comments? This patchset breaks building with SGI UV support enabled: /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c: In function ‘uv_bau_init’: /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c:2130:1: error: ‘trace_uv_bau_message_intr1’ undeclared (first use in this function) /home/hpa/kernel/distwork/arch/x86/platform/uv/tlb_uv.c:2130:1: note: each undeclared identifier is reported only once for each function it appears in -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.10-rc6
Another week, another rc.
And I didn't even need to curse all that much at people. Sure, I
talked smack about some of your hamsters, and I declined a couple of
pull requests, but let's face it, it was pretty halfhearted. Most of
the time things were good.
Which is not to say that rc6 couldn't have been smaller, and I'll
probably be even more upset next week if you try to push stuff that
really shouldn't go in by now, but things are better than in rc5.
And while I'm traveling again, this time the internet works better,
and equally importantly, I actually have my release scripts and kup
install on my pixel now, so the tar-balls and patches are going out as
I write this. For all you luddites that still use ancient technology.
But even if you're a luddite, and haven't yet learnt the guilty
pleasures of a git workflow, you do want to run the latest kernel, I'm
sure. So go out and test that you can't find any regressions. Because
we have fixes all over, even if the diff may be dominated by a DTC
parser patch that comes from changing the shipped files to be
generated by Bison 2.5 rather than 2.4.
Most of the rest is pretty small, even if it's all over.
Architectures: x86, powerpc, mips, arm, s390. Filesystems: ceph and
xfs. And networking and driver updates (sound, wireless, md, gpu,
block)...
Linus
---
Aaron Lu (1):
blkpm: avoid sleep when holding queue lock
Akinobu Mita (1):
frontswap: fix incorrect zeroing and allocation size for frontswap_map
Al Viro (2):
use can_lookup() instead of direct checks of ->i_op->lookup
snd_pcm_link(): fix a leak...
Alex Elder (3):
libceph: must hold mutex for reset_changed_osds()
rbd: don't destroy ceph_opts in rbd_add()
rbd: fix cleanup in rbd_add()
Alex Lyakas (1):
md/raid1: consider WRITE as successful only if at least one
non-Faulty and non-rebuilding drive completed it.
Alex Shi (1):
include/linux/math64.h: add div64_ul()
Alexander Shishkin (2):
usb: chipidea: fix no transceiver case
usb: chipidea: fix id change handling
Andreas Irestål (1):
ASoC: tlv320aic3x: Remove deadlock from snd_soc_dapm_put_volsw_aic3x()
Andrey Vagin (1):
memcg: don't initialize kmem-cache destroying work for root caches
Aneesh Kumar K.V (1):
net/9p: Handle error in zero copy request correctly for 9p2000.u
Arnd Bergmann (3):
crypto: sahara - fix building as module
ARM: 7742/1: topology: export cpu_topology
ARM: 7743/1: compressed/head.S: work around new binutils warning
Ben Greear (1):
Fix lockup related to stop_machine being stuck in __do_softirq.
Ben Hutchings (1):
s390/pci: Implement IRQ functions if !PCI
Benjamin Herrenschmidt (2):
of: Fix locking vs. interrupts
powerpc: Fix missing/delayed calls to irq_work
Benjamin Poirier (1):
netiucv: Hold rtnl between name allocation and device registration.
Benjamin Tissoires (1):
HID: multitouch: prevent memleak with the allocated name
Bing Zhao (1):
Bluetooth: btmrvl: support Marvell Bluetooth device SD8897
Bjørn Mork (1):
qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820
Charles Keepax (1):
ASoC: arizona: Correct AEC loopback enable
Chayan Biswas (1):
Return the result from user admin command IOCTL even in case of failure
Chen Gang (2):
lib/mpi/mpicoder.c: looping issue, need stop when equal to zero,
found by 'EXTRA_FLAGS=-W'.
kernel/audit_tree.c:audit_add_tree_rule(): protect `rule' from
kill_rules()
Chris Wilson (2):
drm/i915: Fix hotplug interrupt enabling for SDVOC
drm/i915: Enable hotplug interrupts after querying hw capabilities.
Christian Borntraeger (3):
s390/pgtable: Fix guest overindication for change bit
s390/pgtable: Save pgste during modify_prot_start/commit
s390/pgtable: make pgste lock an explicit barrier
Dan Carpenter (5):
MAINTAINERS: update NVM EXPRESS DRIVER file list
NVMe: check for integer overflow in nvme_map_user_pages()
pktcdvd: silence static checker warning
ipvs: info leak in __ip_vs_get_dest_entries()
drivers/misc/sgi-gru/grufile.c: fix info leak in gru_get_config_info()
Daniel Borkmann (2):
net: sctp: fix NULL pointer dereference in socket destruction
packet: packet_getname_spkt: make sure string is always 0-terminated
Daniel Vetter (1):
drm/i915: prefer VBT modes for SVDO-LVDS over EDID
Dave Chiluk (1):
ncpfs: fix rmdir returns Device or resource busy
Dave Chinner (4):
xfs: don't emit v5 superblock warnings on write
xfs: fix implicit padding in directory and attr CRC formats
xfs: ensure btree root split sets blkno correctly
xfs: don't shutdown log recovery on validation errors
David Daney (3):
kvm: Add definition of KVM_REG_MIPS
mips/kvm: Use KVM_REG_MIPS and proper size indicators for *_ONE_REG
smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu().
Derek
[PATCH] ACPI / dock: Take ACPI scan lock in write_undock()
From: Rafael J. Wysocki Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be called under acpi_scan_lock, but currently the following scenario violating that requirement is possible: write_undock() handle_eject_request() hotplug_dock_devices() dock_remove_acpi_device() acpi_bus_trim() Fix that by making write_undock() acquire acpi_scan_lock before calling handle_eject_request() as appropriate (begin_undock() is under the lock too in analogy with acpi_dock_deferred_cb()). Signed-off-by: Rafael J. Wysocki Cc: 3.9+ --- drivers/acpi/dock.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-pm/drivers/acpi/dock.c === --- linux-pm.orig/drivers/acpi/dock.c +++ linux-pm/drivers/acpi/dock.c @@ -868,8 +868,10 @@ static ssize_t write_undock(struct devic if (!count) return -EINVAL; + acpi_scan_lock_acquire(); begin_undock(dock_station); ret = handle_eject_request(dock_station, ACPI_NOTIFY_EJECT_REQUEST); + acpi_scan_lock_release(); return ret ? ret: count; } static DEVICE_ATTR(undock, S_IWUSR, NULL, write_undock); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: vt8500: Add support for I2C bus on Wondermedia SoCs
On 15/06/13 23:18, Wolfram Sang wrote: On Sat, Jun 15, 2013 at 09:52:16AM +1200, Tony Prisk wrote: This patch adds support for the I2C bus controllers found on Wondermedia 8xxx-series SoCs. Only master-mode is supported. Signed-off-by: Tony Prisk --- ... +/* REG_TR */ +#define SCL_TIMEOUT(x) (((x) & 0xFF) << 16) I assume this should be << 8 since all regs are 16 bit wide. Fixed it locally and ready to apply. Please confirm or send a proper fix. Rest looks fine. Thanks for the submission! It should be << 8. Please apply your locally corrected version. Regards Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Sat, Jun 15, 2013 at 11:19 PM, Linus Walleij wrote: > On Mon, Jun 10, 2013 at 12:50 PM, Grant Likely > wrote: >> On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij >> wrote: >>> On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely >>> wrote: >>> This is an RFC patch to convert the versatile FPGA irq controller driver to use generic irq chip. It builds on the series that extends the generic chip code to allow a linear irq domain to contain one or more generic irq chips so that each interrupt controller doesn't need to hand code the generic chip setup. I've written this as a proof of concept to see if the new generic irq code does what it needs to. I had to extend it slightly to properly handle the valid mask used by the versatile FPGA driver. Tested on QEMU, but not on real hardware. >>> >>> Is this the same as the one I tested previously? >>> >>> If it need re-testing please push a branch and I'll take it >>> for a spin. >> >> Yes, it's the same, but if you can test the branch I would appreciate >> it. I've done some heavy rework on the irqdomain code that makes >> everything simpler, but also makes it likely that I've broken >> something. >> >> git://git.secretlab.ca/git/linux.git irqdomain/test > > It still works like a charm on the Integrator/AP. > Tested-by: Linus Walleij BTW here is the new hwirq output in /proc/interrupts and it's really nice: root@integrator:/proc cat interrupts CPU0 17: 1845 pic 1 uart-pl010 22: 13716 pic 6 timer 24: 0 pic 8 rtc-pl030 Err: 0 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: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
On Mon, Jun 10, 2013 at 12:50 PM, Grant Likely wrote: > On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij > wrote: >> On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely >> wrote: >> >>> This is an RFC patch to convert the versatile FPGA irq controller driver >>> to use generic irq chip. It builds on the series that extends the >>> generic chip code to allow a linear irq domain to contain one or more >>> generic irq chips so that each interrupt controller doesn't need to hand >>> code the generic chip setup. >>> >>> I've written this as a proof of concept to see if the new generic irq >>> code does what it needs to. I had to extend it slightly to properly >>> handle the valid mask used by the versatile FPGA driver. >>> >>> Tested on QEMU, but not on real hardware. >> >> Is this the same as the one I tested previously? >> >> If it need re-testing please push a branch and I'll take it >> for a spin. > > Yes, it's the same, but if you can test the branch I would appreciate > it. I've done some heavy rework on the irqdomain code that makes > everything simpler, but also makes it likely that I've broken > something. > > git://git.secretlab.ca/git/linux.git irqdomain/test It still works like a charm on the Integrator/AP. Tested-by: Linus Walleij 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: [BUGFIX v2 2/4] ACPI, DOCK: resolve possible deadlock scenarios
On Saturday, June 15, 2013 10:17:42 PM Rafael J. Wysocki wrote:
> On Saturday, June 15, 2013 09:44:28 AM Jiang Liu wrote:
> > On Sat 15 Jun 2013 06:21:02 AM CST, Rafael J. Wysocki wrote:
> > > On Saturday, June 15, 2013 03:27:59 AM Jiang Liu wrote:
> > >> This is a preparation for next patch to avoid breaking bisecting.
> > >> If next patch is applied without this one, it will cause deadlock
> > >> as below:
> > >>
> > >> Case 1:
> > >> [ 31.015593] Possible unsafe locking scenario:
> > >>
> > >> [ 31.018350]CPU0CPU1
> > >> [ 31.019691]
> > >> [ 31.021002] lock(_station->hp_lock);
> > >> [ 31.022327]lock(>crit_sect);
> > >> [ 31.023650]
> > >> lock(_station->hp_lock);
> > >> [ 31.025010] lock(>crit_sect);
> > >> [ 31.026342]
> > >>
> > >> Case 2:
> > >> hotplug_dock_devices()
> > >> mutex_lock(>hp_lock)
> > >> dd->ops->handler()
> > >> register_hotplug_dock_device()
> > >> mutex_lock(>hp_lock)
> > >> [ 34.316570] [ INFO: possible recursive locking detected ]
> > >> [ 34.316573] 3.10.0-rc4 #6 Tainted: G C
> > >> [ 34.316575] -
> > >> [ 34.316577] kworker/0:0/4 is trying to acquire lock:
> > >> [ 34.316579] (_station->hp_lock){+.+.+.}, at:
> > >> [] register_hotplug_dock_device+0x6a/0xbf
> > >> [ 34.316588]
> > >> but task is already holding lock:
> > >> [ 34.316590] (_station->hp_lock){+.+.+.}, at:
> > >> [] hotplug_dock_devices+0x2c/0xda
> > >> [ 34.316595]
> > >> other info that might help us debug this:
> > >> [ 34.316597] Possible unsafe locking scenario:
> > >>
> > >> [ 34.316599]CPU0
> > >> [ 34.316601]
> > >> [ 34.316602] lock(_station->hp_lock);
> > >> [ 34.316605] lock(_station->hp_lock);
> > >> [ 34.316608]
> > >> *** DEADLOCK ***
> > >>
> > >> So fix this deadlock by not taking ds->hp_lock in function
> > >> register_hotplug_dock_device(). This patch also fixes a possible
> > >> race conditions in function dock_event() because previously it
> > >> accesses ds->hotplug_devices list without holding ds->hp_lock.
> > >>
> > >> Signed-off-by: Jiang Liu
> > >> Cc: Len Brown
> > >> Cc: "Rafael J. Wysocki"
> > >> Cc: Bjorn Helgaas
> > >> Cc: Yinghai Lu
> > >> Cc: Yijing Wang
> > >> Cc: linux-a...@vger.kernel.org
> > >> Cc: linux-kernel@vger.kernel.org
> > >> Cc: linux-...@vger.kernel.org
> > >> Cc: # 3.8+
> > >> ---
> > >> drivers/acpi/dock.c| 109
> > >> ++---
> > >> drivers/pci/hotplug/acpiphp_glue.c | 15 +
> > >> include/acpi/acpi_drivers.h| 2 +
> > >> 3 files changed, 82 insertions(+), 44 deletions(-)
> > >>
> > >> diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
> > >> index 02b0563..602bce5 100644
> > >> --- a/drivers/acpi/dock.c
> > >> +++ b/drivers/acpi/dock.c
> > >> @@ -66,7 +66,7 @@ struct dock_station {
> > >> spinlock_t dd_lock;
> > >> struct mutex hp_lock;
> > >> struct list_head dependent_devices;
> > >> -struct list_head hotplug_devices;
> > >> +struct klist hotplug_devices;
> > >>
> > >> struct list_head sibling;
> > >> struct platform_device *dock_device;
> > >> @@ -76,12 +76,18 @@ static int dock_station_count;
> > >>
> > >> struct dock_dependent_device {
> > >> struct list_head list;
> > >> -struct list_head hotplug_list;
> > >> +acpi_handle handle;
> > >> +};
> > >> +
> > >> +struct dock_hotplug_info {
> > >> +struct klist_node node;
> > >> acpi_handle handle;
> > >> const struct acpi_dock_ops *ops;
> > >> void *context;
> > >> };
> > >
> > > Can we please relax a bit and possibly take a step back?
> > >
> > > So since your last reply to me wasn't particularly helpful, I went
> > > through the
> > > code in dock.c and acpiphp_glue.c and I simply think that the whole
> > > hotplug_list thing is simply redundant.
> > >
> > > It looks like instead of using it (or the klist in this patch), we can
> > > add a
> > > "hotlpug_device" flag to dock_dependent_device and set that flag instead
> > > of
> > > adding dd to hotplug_devices or clear it instead of removing dd from that
> > > list.
> > >
> > > That would allow us to avoid the deadlock, because we wouldn't need the
> > > hp_lock
> > > any more and perhaps we could make the code simpler instead of making it
> > > more
> > > complex.
> > >
> > > How does that sound?
> > >
> > > Rafael
> > Hi Rafael,
> >Thanks for comments! It would be great if we could kill the
> > hotplug_devices
> > list so thing gets simple. But there are still some special cases:(
> >
> > As you have mentioned, ds->hp_lock is used to make both addition and
> > removal
> > of
[PATCH] tilepro: work around module link error with gcc 4.7
gcc 4.7.x is emitting calls to __ffsdi2 where previously it used to inline the appropriate ctz instructions. While this needs to be fixed in gcc, it's also easy to avoid having it cause build failures when building with those compilers by exporting __ffsdi2 to modules. Signed-off-by: Chris Metcalf Cc: sta...@kernel.org --- arch/tile/lib/exports.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/tile/lib/exports.c b/arch/tile/lib/exports.c index 4385cb6..a93b02a 100644 --- a/arch/tile/lib/exports.c +++ b/arch/tile/lib/exports.c @@ -84,4 +84,6 @@ uint64_t __ashrdi3(uint64_t, unsigned int); EXPORT_SYMBOL(__ashrdi3); uint64_t __ashldi3(uint64_t, unsigned int); EXPORT_SYMBOL(__ashldi3); +int __ffsdi2(uint64_t); +EXPORT_SYMBOL(__ffsdi2); #endif -- 1.7.10.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ethernet/arc/arc_emac - Add new driver
On 06/16/2013 12:37 AM, Joe Perches wrote:
> On Sun, 2013-06-16 at 00:20 +0400, Alexey Brodkin wrote:
>> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
>> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
>> ARCAngel4/ML50x.
>
>> diff --git a/drivers/net/ethernet/arc/emac_main.c
>> b/drivers/net/ethernet/arc/emac_main.c
> []
>> +if (DUPLEX_FULL == phy_dev->duplex)
>
> Most all kernel code uses "if (var == constant)"
> as that's how most people think.
Makes sense.
> []
>
>> +static int arc_emac_rx(struct net_device *ndev, int budget)
> []
>> +/* Prepare the BD for next cycle */
>> +rx_buff->skb = netdev_alloc_skb_ip_align(ndev, buflen);
>> +if (unlikely(!rx_buff->skb)) {
>> +if (net_ratelimit())
>> +netdev_err(ndev, "cannot allocate skb\n");
>
> Unnecessary OOM message, might as well remove it.
> rx_dropped gives the same info.
With all those error messages I wanted to make life easier (especially
for me) if errors appear. User will immediately know where problem
happened. Indeed "rx_dropped" (when it is used only once in driver) may
show where issue happened, but if later at some point "rx_dropped" will
be incremented in other locations then user won't understand immediately
where error happened.
-Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/1] gpio driver for Intel Baytrail platforms
On Fri, Jun 14, 2013 at 2:14 PM, Mathias Nyman wrote: > [Me] >> I would still vote to put the thing in drivers/pinctrl anyway, >> I am perfectly happy to house pure GPIO drivers there, >> especially if they're obviously masking something more >> pinctrl-like in reality, it will be way more flexible the day that >> you just want to add "this one little quirk for this pin config >> thing", then it'll fit just fine. >> > > I'm fine with having it under drivers/pinctrl as a GPIO driver, either just > as it is, or by using the pinctrl_gpio_range structure and helper functions > such as gpio_to_pad(), once Christian Rupperts patch is accepted. Christian's patch is merged into the pinctrl tree for v3.11. > any naming preference? > pinctrl-baytrail.c Bingo! Because the hardware is a pin controller after all. I know there is some BIOS or ROM very much wanting it to look simpler than it is, but it sure is a pin controller :-) Thanks, 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 v4] ethernet/arc/arc_emac - Add new driver
On Sun, 2013-06-16 at 00:20 +0400, Alexey Brodkin wrote:
> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> ARCAngel4/ML50x.
> diff --git a/drivers/net/ethernet/arc/emac_main.c
> b/drivers/net/ethernet/arc/emac_main.c
[]
> + if (DUPLEX_FULL == phy_dev->duplex)
Most all kernel code uses "if (var == constant)"
as that's how most people think.
[]
> +static int arc_emac_rx(struct net_device *ndev, int budget)
[]
> + /* Prepare the BD for next cycle */
> + rx_buff->skb = netdev_alloc_skb_ip_align(ndev, buflen);
> + if (unlikely(!rx_buff->skb)) {
> + if (net_ratelimit())
> + netdev_err(ndev, "cannot allocate skb\n");
Unnecessary OOM message, might as well remove it.
rx_dropped gives the same info.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
On Sat, Jun 15, 2013 at 10:27:06PM +0200, Rafael J. Wysocki wrote: > On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote: > > Hi all, > > > > So to me it looks like the discussion is going in circles a bit, hence let > > me drop my maintainer-opinion here: > > > > 1. Matthew's patch series here looks reasonable, and if it fixes a bunch > > of systems (which it seems to) it has my Ack and imo should go in. If acpi > > maintainers can smash their Ack onto the acpi parts I'd very much like to > > merge this into drm-intel-next, that should give us the most coverage for > > intel systems. > > > > Len, Rafael, are you ok with the acpi part of this and merging it through > > drm-intel-next? > > It has to go through the ACPI tree because of the ACPICA patch that needs to > be synchronized with the ACPICA upstream. Sorry. No problem, since we're pretty close to the merge window that would have at most resulted in a few more weeks of testing in i915 trees anyway. -rc kernels should still give us plenty of time to catch fallout, if there is any. > That said, I'm going to take this patchset. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] ethernet/arc/arc_emac - Add new driver
Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
instantiated in some legacy ARC (Synopsys) FPGA Boards such as
ARCAngel4/ML50x.
This is based off of current Linus tree.
Signed-off-by: Alexey Brodkin
Reviewed-by: Vineet Gupta
Reviewed-by: Mischa Jonker
Cc: Andy Shevchenko
Cc: Francois Romieu
Cc: Joe Perches
Cc: Vineet Gupta
Cc: Mischa Jonker
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rob Herring
Cc: Paul Gortmaker
Cc: "David S. Miller"
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
---
Hi all,
please take a look at 4th iteration of my patch.
Even though it's already 4th re-spin it still contains some major
changes.
Once again I have to thank Andy Shevchenko & Francois Romieu for their
attention and very valuable advices.
Below is a list of main changes in this re-spin.
1. Functional changes:
1.1. Endian-friendly access to buffer descriptors.
1.2. Introduce separate "arc_emac_rx" for receiving packets and invoke
it from NAPI poll routine.
1.3. Introduce separate "arc_emac_tx_clean" for cleaing transmitted BDs
and invoke it from NAPI poll routine.
1.4. Add memory barriers to make sure pointers to valid data buffers are
set before EMAC may start dealing with it.
1.5. Use "skb_padto" for packets smaller than ETH_ZLEN.
1.6. Move "clock_frequency" as a local variable to "probe". It is only
used once to set poll period in EMAC, so why don't do it in probe.
1.7. "netif_receive_skb" only if next skb was allocated.
1.8. Fix bahavior of "arc_emac_rx" - stop processing on the first BD
owned by EMAC.
1.9. Add more errors to "stats".
1.10. Move "phy_node" variable from private structure to local in
"arc_emac_probe" as used only once.
2. Cosmetics:
2.1. Rename source files - no need to have "arc_" prefix in separate
"arc" folder.
2.1. Add kernel-doc description to data structures in "emac.h".
2.3. Rename some fields in EMAC's private data structure.
2.2. Minor cosmetics.
---
Documentation/devicetree/bindings/net/arc_emac.txt | 38 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/arc/Kconfig | 31 +
drivers/net/ethernet/arc/Makefile |6 +
drivers/net/ethernet/arc/emac.h| 214 +
drivers/net/ethernet/arc/emac_main.c | 832
drivers/net/ethernet/arc/emac_mdio.c | 151
8 files changed, 1274 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/arc_emac.txt
create mode 100644 drivers/net/ethernet/arc/Kconfig
create mode 100644 drivers/net/ethernet/arc/Makefile
create mode 100644 drivers/net/ethernet/arc/emac.h
create mode 100644 drivers/net/ethernet/arc/emac_main.c
create mode 100644 drivers/net/ethernet/arc/emac_mdio.c
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt
b/Documentation/devicetree/bindings/net/arc_emac.txt
new file mode 100644
index 000..bcbc3f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -0,0 +1,38 @@
+* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
+
+Required properties:
+- compatible: Should be "snps,arc-emac"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the EMAC interrupts
+- clock-frequency: CPU frequency. It is needed to calculate and set polling
+period of EMAC.
+- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
+bandwidth of external memory controller might be a limiting factor. That's why
+it's required to specify which data-rate is supported on current SoC or FPGA.
+For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s
is
+supported (100BASE-TX) set "100".
+- phy: PHY device attached to the EMAC via MDIO bus
+
+Child nodes of the driver are the individual PHY devices connected to the
+MDIO bus. They must have a "reg" property given the PHY address on the MDIO
bus.
+
+Optional properties:
+- mac-address: 6 bytes, mac address
+
+Examples:
+
+ ethernet@c0fc2000 {
+ compatible = "snps,arc-emac";
+ reg = <0xc0fc2000 0x3c>;
+ interrupts = <6>;
+ mac-address = [ 00 11 22 33 44 55 ];
+ clock-frequency = <8000>;
+ max-speed = <100>;
+ phy = <>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 4bedae2..98eec48 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -23,6 +23,7 @@ source "drivers/net/ethernet/aeroflex/Kconfig"
source "drivers/net/ethernet/alteon/Kconfig"
source "drivers/net/ethernet/amd/Kconfig"
source "drivers/net/ethernet/apple/Kconfig"
+source "drivers/net/ethernet/arc/Kconfig"
source
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote: > Hi all, > > So to me it looks like the discussion is going in circles a bit, hence let > me drop my maintainer-opinion here: > > 1. Matthew's patch series here looks reasonable, and if it fixes a bunch > of systems (which it seems to) it has my Ack and imo should go in. If acpi > maintainers can smash their Ack onto the acpi parts I'd very much like to > merge this into drm-intel-next, that should give us the most coverage for > intel systems. > > Len, Rafael, are you ok with the acpi part of this and merging it through > drm-intel-next? It has to go through the ACPI tree because of the ACPICA patch that needs to be synchronized with the ACPICA upstream. Sorry. That said, I'm going to take this patchset. > 2. Imo the current amount of quirking we expose to users (we have kernel > options to disable the acpi interface, blacklist platform modules, all > backlights can be tested through sysfs and on top of that xf86-video-intel > has an xorg.conf to select the backlight used by the driver). I haven't > spotted a compelling reason in this thread to add another one, what we > have seems to be good enough to debug backligh issues. > > 3. Also, adding yet another backlight quirk mechanism isn't gonna > magically fix broken systems. > > We _really_ should strive to make this just work and not offer the angry > user another roll of duct-tape for free. > > 4. The currently established priority selection for backlights of platform > > firmware > raw seems to be good enough. Note that the explicit list in > xf86-vidoe-intel is only used as a fallback for really old kernels which > do not expose this information. We could probably rip it out. > > 5. We've recently looked at opregion again and couldn't spot a hint. > Unfortnately it looks like both noodling better information out of Intel > and trying to publish an updated opregion spec seem to be losing games :( > We'll keep on trying though. > > Aside at the end: If the gnome tool indeed has its own backlight code and > doesn't just use that as a fallback if the xrandr backligh property isn't > available, then that's just a serious bug in gnome and should be fixed > asap. But imo that's not something we should try to (nor do I see any way > how to) work around in the kernel. Agreed. Thanks, 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: [RFC] pinctrl: generic: Add DT bindings
Am Samstag, 15. Juni 2013, 21:56:05 schrieb Linus Walleij:
> On Fri, Jun 14, 2013 at 12:39 AM, Laurent Pinchart
>
> wrote:
> > mmcif_pins: mmcif {
> >
> > mux {
> >
> > renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
> > renesas,function = "mmc0";
> >
> > };
> > cfg {
> >
> > renesas,groups = "mmc0_data8_0";
> > renesas,pins = "PORT279";
> > bias-pull-up = <1>;
>
> If I understood your code correctly that last statement can *optionally*
> be written like just:
>
> bias-pull-up;
>
> Without the parameter?
>
> I think that Heiko's implementation does this anyway.
Yep, with the fixes-series from yesterday the bias-pull-* now have a better
default value of <1>.
so you can do
bias-pull-up;
which is then identical to the
bias-pull-up = <1>;
above (both are valid of course).
Disable would the be either
bias-disable;
or
bias-pull-up = <0>;
A driver should probably handle both, as both are valid pinconf options or
this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUGFIX v2 2/4] ACPI, DOCK: resolve possible deadlock scenarios
On Saturday, June 15, 2013 09:44:28 AM Jiang Liu wrote:
> On Sat 15 Jun 2013 06:21:02 AM CST, Rafael J. Wysocki wrote:
> > On Saturday, June 15, 2013 03:27:59 AM Jiang Liu wrote:
> >> This is a preparation for next patch to avoid breaking bisecting.
> >> If next patch is applied without this one, it will cause deadlock
> >> as below:
> >>
> >> Case 1:
> >> [ 31.015593] Possible unsafe locking scenario:
> >>
> >> [ 31.018350]CPU0CPU1
> >> [ 31.019691]
> >> [ 31.021002] lock(_station->hp_lock);
> >> [ 31.022327]lock(>crit_sect);
> >> [ 31.023650]lock(_station->hp_lock);
> >> [ 31.025010] lock(>crit_sect);
> >> [ 31.026342]
> >>
> >> Case 2:
> >> hotplug_dock_devices()
> >> mutex_lock(>hp_lock)
> >> dd->ops->handler()
> >> register_hotplug_dock_device()
> >> mutex_lock(>hp_lock)
> >> [ 34.316570] [ INFO: possible recursive locking detected ]
> >> [ 34.316573] 3.10.0-rc4 #6 Tainted: G C
> >> [ 34.316575] -
> >> [ 34.316577] kworker/0:0/4 is trying to acquire lock:
> >> [ 34.316579] (_station->hp_lock){+.+.+.}, at:
> >> [] register_hotplug_dock_device+0x6a/0xbf
> >> [ 34.316588]
> >> but task is already holding lock:
> >> [ 34.316590] (_station->hp_lock){+.+.+.}, at:
> >> [] hotplug_dock_devices+0x2c/0xda
> >> [ 34.316595]
> >> other info that might help us debug this:
> >> [ 34.316597] Possible unsafe locking scenario:
> >>
> >> [ 34.316599]CPU0
> >> [ 34.316601]
> >> [ 34.316602] lock(_station->hp_lock);
> >> [ 34.316605] lock(_station->hp_lock);
> >> [ 34.316608]
> >> *** DEADLOCK ***
> >>
> >> So fix this deadlock by not taking ds->hp_lock in function
> >> register_hotplug_dock_device(). This patch also fixes a possible
> >> race conditions in function dock_event() because previously it
> >> accesses ds->hotplug_devices list without holding ds->hp_lock.
> >>
> >> Signed-off-by: Jiang Liu
> >> Cc: Len Brown
> >> Cc: "Rafael J. Wysocki"
> >> Cc: Bjorn Helgaas
> >> Cc: Yinghai Lu
> >> Cc: Yijing Wang
> >> Cc: linux-a...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-...@vger.kernel.org
> >> Cc: # 3.8+
> >> ---
> >> drivers/acpi/dock.c| 109
> >> ++---
> >> drivers/pci/hotplug/acpiphp_glue.c | 15 +
> >> include/acpi/acpi_drivers.h| 2 +
> >> 3 files changed, 82 insertions(+), 44 deletions(-)
> >>
> >> diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
> >> index 02b0563..602bce5 100644
> >> --- a/drivers/acpi/dock.c
> >> +++ b/drivers/acpi/dock.c
> >> @@ -66,7 +66,7 @@ struct dock_station {
> >>spinlock_t dd_lock;
> >>struct mutex hp_lock;
> >>struct list_head dependent_devices;
> >> - struct list_head hotplug_devices;
> >> + struct klist hotplug_devices;
> >>
> >>struct list_head sibling;
> >>struct platform_device *dock_device;
> >> @@ -76,12 +76,18 @@ static int dock_station_count;
> >>
> >> struct dock_dependent_device {
> >>struct list_head list;
> >> - struct list_head hotplug_list;
> >> + acpi_handle handle;
> >> +};
> >> +
> >> +struct dock_hotplug_info {
> >> + struct klist_node node;
> >>acpi_handle handle;
> >>const struct acpi_dock_ops *ops;
> >>void *context;
> >> };
> >
> > Can we please relax a bit and possibly take a step back?
> >
> > So since your last reply to me wasn't particularly helpful, I went through
> > the
> > code in dock.c and acpiphp_glue.c and I simply think that the whole
> > hotplug_list thing is simply redundant.
> >
> > It looks like instead of using it (or the klist in this patch), we can add a
> > "hotlpug_device" flag to dock_dependent_device and set that flag instead of
> > adding dd to hotplug_devices or clear it instead of removing dd from that
> > list.
> >
> > That would allow us to avoid the deadlock, because we wouldn't need the
> > hp_lock
> > any more and perhaps we could make the code simpler instead of making it
> > more
> > complex.
> >
> > How does that sound?
> >
> > Rafael
> Hi Rafael,
>Thanks for comments! It would be great if we could kill the
> hotplug_devices
> list so thing gets simple. But there are still some special cases:(
>
> As you have mentioned, ds->hp_lock is used to make both addition and
> removal
> of hotplug devices wait for us to complete walking ds->hotplug_devices.
> So it acts as two roles:
> 1) protect the hotplug_devices list,
> 2) serialize unregister_hotplug_dock_device() and
> hotplug_dock_devices() so
> the dock driver doesn't access registered handler and associated data
> structure
> once returing from unregister_hotplug_dock_device().
When it returns from unregister_hotplug_dock_device(), nothing
Re: [RFC 5/5] security: smack: add kmem_cache for smack_master_list allocations
On 6/13/2013 8:29 AM, Tomasz Stanislawski wrote:
> On ARM, sizeof(struct smack_master_list) == 12. Allocation by kmalloc() uses a
> 32-byte-long chunk to allocate 12 bytes. Just ask ksize(). It means that 63%
> of memory is simply wasted for padding bytes.
>
> The problem is fixed in this patch by using kmem_cache. The cache allocates
> struct smack_master_list using 16-byte-long chunks according to ksize(). This
> reduces amount of used memory by 50%.
As with patch 4, I need to see performance numbers. Saving 50%
is good, but if there are 20,000 rules you're only saving 320K
of memory.
>
> Signed-off-by: Tomasz Stanislawski
> ---
> security/smack/smack.h |7 +++
> security/smack/smack_lsm.c |8
> security/smack/smackfs.c |8 ++--
> 3 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 38ba673..463f818 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -194,6 +194,12 @@ struct smk_audit_info {
> struct smack_audit_data sad;
> #endif
> };
> +
> +struct smack_master_list {
> + struct list_headlist;
> + struct smack_rule *smk_rule;
> +};
> +
> /*
> * These functions are in smack_lsm.c
> */
> @@ -235,6 +241,7 @@ extern struct list_head smk_netlbladdr_list;
>
> /* Cache for fast and thrifty allocations */
> extern struct kmem_cache *smack_rule_cache;
> +extern struct kmem_cache *smack_master_list_cache;
>
> extern struct security_operations smack_ops;
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 7aa696a..1d4a1b0 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3566,6 +3566,7 @@ static __init void init_smack_known_list(void)
>
> /* KMEM caches for fast and thrifty allocations */
> struct kmem_cache *smack_rule_cache;
> +struct kmem_cache *smack_master_list_cache;
>
> /**
> * smack_init - initialize the smack system
> @@ -3584,9 +3585,16 @@ static __init int smack_init(void)
> if (!smack_rule_cache)
> return -ENOMEM;
>
> + smack_master_list_cache = KMEM_CACHE(smack_master_list, 0);
> + if (!smack_master_list_cache) {
> + kmem_cache_destroy(smack_rule_cache);
> + return -ENOMEM;
> + }
> +
> tsp = new_task_smack(smack_known_floor.smk_known,
> smack_known_floor.smk_known, GFP_KERNEL);
> if (tsp == NULL) {
> + kmem_cache_destroy(smack_master_list_cache);
> kmem_cache_destroy(smack_rule_cache);
> return -ENOMEM;
> }
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index c08b1ec..c7a1b0d 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -104,11 +104,6 @@ LIST_HEAD(smk_netlbladdr_list);
> * Rule lists are maintained for each label.
> * This master list is just for reading /smack/load and /smack/load2.
> */
> -struct smack_master_list {
> - struct list_headlist;
> - struct smack_rule *smk_rule;
> -};
> -
> LIST_HEAD(smack_rule_list);
>
> struct smack_parsed_rule {
> @@ -233,7 +228,8 @@ static int smk_set_access(struct smack_parsed_rule *srp,
>* it needs to get added for reporting.
>*/
> if (global) {
> - smlp = kzalloc(sizeof(*smlp), GFP_KERNEL);
> + smlp = kmem_cache_zalloc(smack_master_list_cache,
> + GFP_KERNEL);
> if (smlp != NULL) {
> smlp->smk_rule = sp;
> list_add_rcu(>list, _rule_list);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] security: smack: add kmem_cache for smack_rule allocations
On 6/13/2013 8:29 AM, Tomasz Stanislawski wrote:
> On ARM, sizeof(struct smack_rule)==20. Allocation by kmalloc() uses a
> 32-byte-long chunk to allocate 20 bytes. Just ask ksize(). It means that 40%
> of memory is simply wasted for padding bytes.
>
> The problem is fixed in this patch by using kmem_cache. The cache allocates
> struct smack_rule using 24-byte-long chunks according to ksize(). This reduces
> amount of used memory by 25%.
I'm not opposed to this change, but could I see some performance
numbers to justify it? In particular, I'm concerned about the rules
load impact.
> Signed-off-by: Tomasz Stanislawski
> ---
> security/smack/smack.h |3 +++
> security/smack/smack_lsm.c | 11 ++-
> security/smack/smackfs.c |2 +-
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 8ad3095..38ba673 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -233,6 +233,9 @@ extern struct mutex smack_known_lock;
> extern struct list_head smack_known_list;
> extern struct list_head smk_netlbladdr_list;
>
> +/* Cache for fast and thrifty allocations */
> +extern struct kmem_cache *smack_rule_cache;
> +
> extern struct security_operations smack_ops;
>
> /*
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index d52c780..7aa696a 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3564,6 +3564,9 @@ static __init void init_smack_known_list(void)
> list_add(_known_web.list, _known_list);
> }
>
> +/* KMEM caches for fast and thrifty allocations */
> +struct kmem_cache *smack_rule_cache;
> +
> /**
> * smack_init - initialize the smack system
> *
> @@ -3577,10 +3580,16 @@ static __init int smack_init(void)
> if (!security_module_enable(_ops))
> return 0;
>
> + smack_rule_cache = KMEM_CACHE(smack_rule, 0);
> + if (!smack_rule_cache)
> + return -ENOMEM;
> +
> tsp = new_task_smack(smack_known_floor.smk_known,
> smack_known_floor.smk_known, GFP_KERNEL);
> - if (tsp == NULL)
> + if (tsp == NULL) {
> + kmem_cache_destroy(smack_rule_cache);
> return -ENOMEM;
> + }
>
> printk(KERN_INFO "Smack: Initializing.\n");
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index e8c57f3..c08b1ec 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -217,7 +217,7 @@ static int smk_set_access(struct smack_parsed_rule *srp,
> }
>
> if (found == 0) {
> - sp = kzalloc(sizeof(*sp), GFP_KERNEL);
> + sp = kmem_cache_zalloc(smack_rule_cache, GFP_KERNEL);
> if (sp == NULL) {
> rc = -ENOMEM;
> goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pinctrl: generic: Add DT bindings
On Fri, Jun 14, 2013 at 12:39 AM, Laurent Pinchart
wrote:
> mmcif_pins: mmcif {
> mux {
> renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
> renesas,function = "mmc0";
> };
> cfg {
> renesas,groups = "mmc0_data8_0";
> renesas,pins = "PORT279";
> bias-pull-up = <1>;
If I understood your code correctly that last statement can *optionally*
be written like just:
bias-pull-up;
Without the parameter?
I think that Heiko's implementation does this 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: [BUGFIX v2 1/4] ACPI, DOCK: initialize dock subsystem before scanning PCI root buses
On Saturday, June 15, 2013 06:05:31 PM Jiang Liu wrote:
> On 06/15/2013 02:51 PM, Yinghai Lu wrote:
> > On Fri, Jun 14, 2013 at 12:27 PM, Jiang Liu wrote:
> >> Changeset "3b63aaa70e1 PCI: acpiphp: Do not use ACPI PCI subdriver
> >> mechanism" causes a regression which breaks ACPI dock support,
> >> please refer to https://bugzilla.kernel.org/show_bug.cgi?id=59501
> >>
> >> The root cause is that changeset 3b63aaa70e1 changed the relative
> >> initialization order of ACPI dock subsystem and acpiphp driver,
> >> and acpiphp driver has dependency on ACPI dock subsystem's
> >> initialization result, so that acpiphp can't correctly detect ACPI
> >> dock stations now.
> >>
> >> On the other hand, ACPI dock is a built-in driver, so we could
> >> explicitly initialize it before the acpiphp driver is used.
> >>
> >> Signed-off-by: Jiang Liu
> >> Reported-by: Alexander E. Patrakov
> >> Tested-by: Alexander E. Patrakov
> >> Cc: "Rafael J. Wysocki"
> >> Cc: linux-a...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: # 3.9+
> >> ---
> >> drivers/acpi/dock.c | 7 +--
> >> drivers/acpi/internal.h | 5 +
> >> drivers/acpi/scan.c | 1 +
> >> 3 files changed, 7 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
> >> index 4fdea38..02b0563 100644
> >> --- a/drivers/acpi/dock.c
> >> +++ b/drivers/acpi/dock.c
> >> @@ -1033,7 +1033,7 @@ find_dock_and_bay(acpi_handle handle, u32 lvl, void
> >> *context, void **rv)
> >> return AE_OK;
> >> }
> >>
> >> -static int __init dock_init(void)
> >> +int __init acpi_dock_init(void)
> >> {
> >> if (acpi_disabled)
> >> return 0;
> >> @@ -1062,9 +1062,4 @@ static void __exit dock_exit(void)
> >> dock_remove(dock_station);
> >> }
> >>
> >> -/*
> >> - * Must be called before drivers of devices in dock, otherwise we can't
> >> know
> >> - * which devices are in a dock
> >> - */
> >> -subsys_initcall(dock_init);
> >> module_exit(dock_exit);
> >
> > why not remove dock_exit?
> I have a pending patchset to clean up dock driver, Rafael suggested to
> focus on bugfix first, so I will send out the clean up patchset later.
Well, you can remove dock_exit() in the same patch. This is kind of not
directly related to the fix, but since you're changing it from modular to
non-modular, it'd be prudent to remove all of the "modular" code in the
process.
Thanks,
Rafael
> >> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> >> index 297cbf4..c610a76 100644
> >> --- a/drivers/acpi/internal.h
> >> +++ b/drivers/acpi/internal.h
> >> @@ -40,6 +40,11 @@ void acpi_container_init(void);
> >> #else
> >> static inline void acpi_container_init(void) {}
> >> #endif
> >> +#ifdef CONFIG_ACPI_DOCK
> >> +void acpi_dock_init(void);
> >> +#else
> >> +static inline void acpi_dock_init(void) {}
> >> +#endif
> >> #ifdef CONFIG_ACPI_HOTPLUG_MEMORY
> >> void acpi_memory_hotplug_init(void);
> >> #else
> >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> >> index 44225cb..4148163 100644
> >> --- a/drivers/acpi/scan.c
> >> +++ b/drivers/acpi/scan.c
> >> @@ -2045,6 +2045,7 @@ int __init acpi_scan_init(void)
> >> acpi_lpss_init();
> >> acpi_container_init();
> >> acpi_memory_hotplug_init();
> >> + acpi_dock_init();
> >>
> >> mutex_lock(_scan_lock);
> >> /*
> >> --
> >> 1.8.1.2
> >>
>
--
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: [RFC 3/5] security: smack: fix memleak in smk_write_rules_list()
On 6/13/2013 8:29 AM, Tomasz Stanislawski wrote:
> The smack_parsed_rule structure is allocated. If a rule is successfully
> installed then the last reference to the object is lost. This patch fixes
> this
> leak. Moreover smack_parsed_rule is allocated on stack because it no longer
> needed ofter smk_write_rules_list() is finished.
>
> Signed-off-by: Tomasz Stanislawski
It looks like this was introduced with the change-rule support.
Prior to that, the rule passed into smk_set_access() was added
to the rule list if it was new. The change-rule support added a
new structure and missed the fact the rule was already allocated.
The patch needs to be rebased so that it does not depend on the
changes from patches 1 and 2 of the set.
> ---
> security/smack/smackfs.c | 30 ++
> 1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 46f111e..e8c57f3 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -447,7 +447,7 @@ static ssize_t smk_write_rules_list(struct file *file,
> const char __user *buf,
> struct mutex *rule_lock, int format)
> {
> struct smack_known *skp;
> - struct smack_parsed_rule *rule;
> + struct smack_parsed_rule rule;
> char data[SMK_LOAD2LEN + 1];
> int rc = -EINVAL;
> int load = 0;
> @@ -475,49 +475,39 @@ static ssize_t smk_write_rules_list(struct file *file,
> const char __user *buf,
> goto out;
> }
>
> - rule = kzalloc(sizeof(*rule), GFP_KERNEL);
> - if (rule == NULL) {
> - rc = -ENOMEM;
> - goto out;
> - }
> -
> if (format == SMK_LONG_FMT) {
> /*
>* Be sure the data string is terminated.
>*/
> data[count] = '\0';
> - if (smk_parse_long_rule(data, rule, 1, 0))
> - goto out_free_rule;
> + if (smk_parse_long_rule(data, , 1, 0))
> + goto out;
> } else if (format == SMK_CHANGE_FMT) {
> data[count] = '\0';
> - if (smk_parse_long_rule(data, rule, 1, 1))
> - goto out_free_rule;
> + if (smk_parse_long_rule(data, , 1, 1))
> + goto out;
> } else {
> /*
>* More on the minor hack for backward compatibility
>*/
> if (count == (SMK_OLOADLEN))
> data[SMK_OLOADLEN] = '-';
> - if (smk_parse_rule(data, rule, 1))
> - goto out_free_rule;
> + if (smk_parse_rule(data, , 1))
> + goto out;
> }
>
>
> if (rule_list == NULL) {
> load = 1;
> - skp = smk_find_entry(rule->smk_subject);
> + skp = smk_find_entry(rule.smk_subject);
> rule_list = >smk_rules;
> rule_lock = >smk_rules_lock;
> }
>
> - rc = smk_set_access(rule, rule_list, rule_lock, load);
> - if (rc == 0) {
> + rc = smk_set_access(, rule_list, rule_lock, load);
> + if (rc == 0)
> rc = count;
> - goto out;
> - }
>
> -out_free_rule:
> - kfree(rule);
> out:
> return rc;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: pinctrl:when two device use the same pin
On Sat, Jun 15, 2013 at 2:10 PM, xulinuxkernel wrote: > In my company,on the chip, the spi nor flash and nand flash use the same > four pins.In this case,it must be different devices and different drivers. > In the "Runtime pinmuxing", I think it is one device has two different > state. This does not sound like runtime pin muxing. This sounds like you have *either* a NOT flash *or* a NAND flash connected to your chip, not both NOR and NAND at the same time. Just do not register the device nor add the pinctrl tables for the one that is not used on a certain target system. Atleast do not add the pinctrl tables for NOR when using NAND and vice versa. > when spi flash use the pin.then nand request the pin it will fail,I just add > the current(nand) process in an wait queue,after the spi flash pinctl_put, > spi will wake_up the wait queue. > > when nand use the pin,if spi request fail, I add the spi process on the same > wait queue,when nand release the pin,nand will wake up the wait queue. > Is that ok? This sounds like a horribly complicated hack to do something very simple. Look at the problem from a higher level. Why do you do this? Obviously you have either NOR or NAND connected? Don't you know from the system board file or device tree which one it is? 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: [RFC 2/5] security: smack: avoid kmalloc() in smk_parse_long_rule()
On 6/13/2013 8:29 AM, Tomasz Stanislawski wrote:
> Function smk_parse_long_rule() allocates a number of temporary strings on heap
> (kmalloc cache). Moreover, the sizes of those allocations might be large if
> user calls write() for a long chunk. A big kmalloc triggers a heavy reclaim
> havoc and it is very likely to fail.
>
> This patch introduces smk_parse_substrings() function that parses a string
> into
> substring separated by whitespaces. The buffer for substring is preallocated.
> It must store substring the worst case scenario which is SMK_LOAD2LEN in case
> of long rule parsing.
>
> The buffer is allocated on stack what is slightly faster than kmalloc().
>
> Signed-off-by: Tomasz Stanislawski
There is hope for this patch, but it will need changes.
> ---
> security/smack/smackfs.c | 67
> +++---
> 1 file changed, 33 insertions(+), 34 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 9a3cd0d..46f111e 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -364,6 +364,33 @@ static int smk_parse_rule(const char *data, struct
> smack_parsed_rule *rule,
> }
>
> /**
> + * smk_parse_strings - parse white-space separated substring from a string
> + * @src: a long string to be parsed, null terminated
> + * @dst: a buffer for substrings, should be at least strlen(src)+1 bytes
> + * @args: table for parsed substring
> + * @size: number of slots in args table
> + *
> + * Returns number of parsed substrings
> + */
> +static int smk_parse_substrings(const char *src, char *dst,
> + char *args[], int size)
> +{
> + int cnt;
> +
> + for (cnt = 0; cnt < size; ++cnt) {
> + src = skip_spaces(src);
> + if (*src == 0)
> + break;
> + args[cnt] = dst;
> + for (; *src && !isspace(*src); ++src, ++dst)
> + *dst = *src;
> + *(dst++) = 0;
> + }
> +
> + return cnt;
> +}
> +
> +/**
> * smk_parse_long_rule - parse Smack rule from rule string
> * @data: string to be parsed, null terminated
> * @rule: Will be filled with Smack parsed rule
> @@ -375,48 +402,20 @@ static int smk_parse_rule(const char *data, struct
> smack_parsed_rule *rule,
> static int smk_parse_long_rule(const char *data, astruct smack_parsed_rule
> *rule,
> int import, int change)
> {
> - char *subject;
> - char *object;
> - char *access1;
> - char *access2;
> - int datalen;
> + char tmp[SMK_LOAD2LEN + 1];
As mentioned in patch 1 of this set, you can't put something this
large on the stack. You could however use the same logic below on
a single allocated buffer and reduce the number of kzallocs from
four to one. That would get most of the improvement you're looking
for.
> + char *args[4];
> int rc = -1;
>
> - /* This is inefficient */
> - datalen = strlen(data);
> -
> - /* Our first element can be 64 + \0 with no spaces */
> - subject = kzalloc(datalen + 1, GFP_KERNEL);
> - if (subject == NULL)
> - return -1;
> - object = kzalloc(datalen, GFP_KERNEL);
> - if (object == NULL)
> - goto free_out_s;
> - access1 = kzalloc(datalen, GFP_KERNEL);
> - if (access1 == NULL)
> - goto free_out_o;
> - access2 = kzalloc(datalen, GFP_KERNEL);
> - if (access2 == NULL)
> - goto free_out_a;
> -
> if (change) {
> - if (sscanf(data, "%s %s %s %s",
> - subject, object, access1, access2) == 4)
> - rc = smk_fill_rule(subject, object, access1, access2,
> + if (smk_parse_substrings(data, tmp, args, 4) == 4)
> + rc = smk_fill_rule(args[0], args[1], args[2], args[3],
> rule, import, 0);
> } else {
> - if (sscanf(data, "%s %s %s", subject, object, access1) == 3)
> - rc = smk_fill_rule(subject, object, access1, NULL,
> + if (smk_parse_substrings(data, tmp, args, 3) == 3)
> + rc = smk_fill_rule(args[0], args[1], args[2], NULL,
> rule, import, 0);
> }
>
> - kfree(access2);
> -free_out_a:
> - kfree(access1);
> -free_out_o:
> - kfree(object);
> -free_out_s:
> - kfree(subject);
> return rc;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/5] security: smack: avoid kmalloc allocations while loading a rule string
On 6/13/2013 8:29 AM, Tomasz Stanislawski wrote:
> The maximal length for a rule line for long format is introduced as
> SMK_LOAD2LEN. This allows a buffer for a rule string to be allocated
> on a stack instead of a heap (aka kmalloc cache).
>
> Limiting the length of a rule line helps to avoid allocations of a very long
> contiguous buffer from a heap if user calls write() for a very long chunk.
> Such an allocation often causes a lot swapper/writeback havoc and it is very
> likely to fails.
>
> Moreover, stack allocation is slightly faster than from kmalloc.
>
> Signed-off-by: Tomasz Stanislawski
Please see the explanation below.
Nacked-by: Casey Schaufler
> ---
> security/smack/smackfs.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 53a08b8..9a3cd0d 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -137,6 +137,7 @@ const char *smack_cipso_option = SMACK_CIPSO_OPTION;
> * SMK_ACCESS: Maximum possible combination of access permissions
> * SMK_ACCESSLEN: Maximum length for a rule access field
> * SMK_LOADLEN: Smack rule length
> + * SMK_LOAD2LEN: Smack maximal long rule length excluding \0
> */
> #define SMK_OACCESS "rwxa"
> #define SMK_ACCESS "rwxat"
> @@ -144,6 +145,7 @@ const char *smack_cipso_option = SMACK_CIPSO_OPTION;
> #define SMK_ACCESSLEN(sizeof(SMK_ACCESS) - 1)
> #define SMK_OLOADLEN (SMK_LABELLEN + SMK_LABELLEN + SMK_OACCESSLEN)
> #define SMK_LOADLEN (SMK_LABELLEN + SMK_LABELLEN + SMK_ACCESSLEN)
> +#define SMK_LOAD2LEN (2 * SMK_LONGLABEL + SMK_ACCESSLEN + 2)
>
> /*
> * Stricly for CIPSO level manipulation.
> @@ -447,8 +449,7 @@ static ssize_t smk_write_rules_list(struct file *file,
> const char __user *buf,
> {
> struct smack_known *skp;
> struct smack_parsed_rule *rule;
> - char *data;
> - int datalen;
> + char data[SMK_LOAD2LEN + 1];
That puts over 512 bytes on the stack. The reason that the code
uses a temporary allocation is that 512 bytes to considerably
beyond what is considered reasonable to put on the kernel stack.
As reasonable as this approach is in user space code, it is not
appropriate in the kernel.
> int rc = -EINVAL;
> int load = 0;
>
> @@ -465,13 +466,10 @@ static ssize_t smk_write_rules_list(struct file *file,
> const char __user *buf,
>*/
> if (count != SMK_OLOADLEN && count != SMK_LOADLEN)
> return -EINVAL;
> - datalen = SMK_LOADLEN;
> - } else
> - datalen = count + 1;
> + }
>
> - data = kzalloc(datalen, GFP_KERNEL);
> - if (data == NULL)
> - return -ENOMEM;
> + if (count > SMK_LOAD2LEN)
> + count = SMK_LOAD2LEN;
>
> if (copy_from_user(data, buf, count) != 0) {
> rc = -EFAULT;
> @@ -522,7 +520,6 @@ static ssize_t smk_write_rules_list(struct file *file,
> const char __user *buf,
> out_free_rule:
> kfree(rule);
> out:
> - kfree(data);
> return rc;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug report about acpiphp
yes, it works with them. Those patches will be included in the next rc of the kernel 3.10? 2013/6/15 Yinghai Lu : > On Sat, Jun 15, 2013 at 8:34 AM, diego fanesi wrote: >> I would like to report a bug about the module acpiphp. I don't know if >> this is the right place, if it isn't please tell me where I should >> write and I will do it. >> >> description: docking station hotplug working on 3.5.0 kernel but not >> in previous and next kernel releases >> hardware: sony vaio serie z SVZ1311C5E + Docking station VGP-PRZ20A >> distro: Ubuntu precise, kernels compiled from the source in kernel.org >> >> The problem is about connecting the docking station after the boot. >> with kernel 3.5.0: >> when I connect the docking station I can see the following log lines (dmesg): >> [ 2442.046921] acpiphp: Slot [1-1] registered >> [ 2442.046945] acpiphp: Slot [2] registered >> [ 2442.046968] acpiphp: Slot [3] registered >> [ 2442.047056] acpiphp: Slot [1-2] registered >> [ 2442.047066] acpiphp_glue: sibling found, but _SUN doesn't match! >> [ 2442.047169] acpiphp: Slot [1-3] registered >> [ 2442.047229] acpiphp: Slot [1-4] registered >> [ 2442.047300] acpiphp: Slot [1-5] registered >> >> after that all the devices are available in the system. I can use the >> external network, the bluray device, and the usb ports available in >> the docking station. >> if I unload the acpiphp module the hotplug doesn't work, meaning no >> log lines and devices not usable. >> >> with any other kernel (I tried also with 3.10rc5): >> when I connect the docking station I cannot see the log lines >> specified above, and the devices are not available. I tried with and >> without acpiphp loaded. >> >> I didn't tried with other 3.5 kernel versions. I tried with 3.7 and >> 3.8 and it is not working >> >> If I connect the docking station before the boot with a non 3.5.0 >> kernel and I unplug it I can continue to see the devices available but >> of course not working. > > please check v3.10-rc5 + > https://patchwork.kernel.org/patch/2723671/ > https://patchwork.kernel.org/patch/2723721/ > https://patchwork.kernel.org/patch/2723751/ > https://patchwork.kernel.org/patch/2723791/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Contact me
Good day friend I have a secured business proposal for you. If you are interested please contact me for more details of my Business Proposal. Your earliest response to this letter will be appreciated. Yours Sincerely, Mrs.Kang. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
On Sat, Jun 15, 2013 at 08:29:42PM +0200, Daniel Vetter wrote: > Aside at the end: If the gnome tool indeed has its own backlight code and > doesn't just use that as a fallback if the xrandr backligh property isn't > available, then that's just a serious bug in gnome and should be fixed > asap. But imo that's not something we should try to (nor do I see any way > how to) work around in the kernel. It's only used if there's no backlight property on the display. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vfree: don't schedule free_work() if llist_add() returns F
vfree() only needs schedule_work(>wq) if p->list was empty,
otherwise vfree_deferred->wq is already pending or it is running
and didn't do llist_del_all() yet.
Signed-off-by: Oleg Nesterov
---
mm/vmalloc.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d365724..2b8f644 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1524,7 +1524,6 @@ static void __vunmap(const void *addr, int
deallocate_pages)
* conventions for vfree() arch-depenedent would be a really bad idea)
*
* NOTE: assumes that the object at *addr has a size >= sizeof(llist_node)
- *
*/
void vfree(const void *addr)
{
@@ -1536,8 +1535,8 @@ void vfree(const void *addr)
return;
if (unlikely(in_interrupt())) {
struct vfree_deferred *p = &__get_cpu_var(vfree_deferred);
- llist_add((struct llist_node *)addr, >list);
- schedule_work(>wq);
+ if (llist_add((struct llist_node *)addr, >list))
+ schedule_work(>wq);
} else
__vunmap(addr, 1);
}
--
1.5.5.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: bug report about acpiphp
On Sat, Jun 15, 2013 at 8:34 AM, diego fanesi wrote: > I would like to report a bug about the module acpiphp. I don't know if > this is the right place, if it isn't please tell me where I should > write and I will do it. > > description: docking station hotplug working on 3.5.0 kernel but not > in previous and next kernel releases > hardware: sony vaio serie z SVZ1311C5E + Docking station VGP-PRZ20A > distro: Ubuntu precise, kernels compiled from the source in kernel.org > > The problem is about connecting the docking station after the boot. > with kernel 3.5.0: > when I connect the docking station I can see the following log lines (dmesg): > [ 2442.046921] acpiphp: Slot [1-1] registered > [ 2442.046945] acpiphp: Slot [2] registered > [ 2442.046968] acpiphp: Slot [3] registered > [ 2442.047056] acpiphp: Slot [1-2] registered > [ 2442.047066] acpiphp_glue: sibling found, but _SUN doesn't match! > [ 2442.047169] acpiphp: Slot [1-3] registered > [ 2442.047229] acpiphp: Slot [1-4] registered > [ 2442.047300] acpiphp: Slot [1-5] registered > > after that all the devices are available in the system. I can use the > external network, the bluray device, and the usb ports available in > the docking station. > if I unload the acpiphp module the hotplug doesn't work, meaning no > log lines and devices not usable. > > with any other kernel (I tried also with 3.10rc5): > when I connect the docking station I cannot see the log lines > specified above, and the devices are not available. I tried with and > without acpiphp loaded. > > I didn't tried with other 3.5 kernel versions. I tried with 3.7 and > 3.8 and it is not working > > If I connect the docking station before the boot with a non 3.5.0 > kernel and I unplug it I can continue to see the devices available but > of course not working. please check v3.10-rc5 + https://patchwork.kernel.org/patch/2723671/ https://patchwork.kernel.org/patch/2723721/ https://patchwork.kernel.org/patch/2723751/ https://patchwork.kernel.org/patch/2723791/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
Hi all, So to me it looks like the discussion is going in circles a bit, hence let me drop my maintainer-opinion here: 1. Matthew's patch series here looks reasonable, and if it fixes a bunch of systems (which it seems to) it has my Ack and imo should go in. If acpi maintainers can smash their Ack onto the acpi parts I'd very much like to merge this into drm-intel-next, that should give us the most coverage for intel systems. Len, Rafael, are you ok with the acpi part of this and merging it through drm-intel-next? 2. Imo the current amount of quirking we expose to users (we have kernel options to disable the acpi interface, blacklist platform modules, all backlights can be tested through sysfs and on top of that xf86-video-intel has an xorg.conf to select the backlight used by the driver). I haven't spotted a compelling reason in this thread to add another one, what we have seems to be good enough to debug backligh issues. 3. Also, adding yet another backlight quirk mechanism isn't gonna magically fix broken systems. We _really_ should strive to make this just work and not offer the angry user another roll of duct-tape for free. 4. The currently established priority selection for backlights of platform > firmware > raw seems to be good enough. Note that the explicit list in xf86-vidoe-intel is only used as a fallback for really old kernels which do not expose this information. We could probably rip it out. 5. We've recently looked at opregion again and couldn't spot a hint. Unfortnately it looks like both noodling better information out of Intel and trying to publish an updated opregion spec seem to be losing games :( We'll keep on trying though. Aside at the end: If the gnome tool indeed has its own backlight code and doesn't just use that as a fallback if the xrandr backligh property isn't available, then that's just a serious bug in gnome and should be fixed asap. But imo that's not something we should try to (nor do I see any way how to) work around in the kernel. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv1] kvm guest: fix uninitialized kvmclock read by KVM guest
Due to unintialized kvmclock read KVM guest is hanging on SMP boot stage.
If unintialized memory contains fatal garbage then hang reproduction is 100%.
Unintialized memory is allocated by memblock_alloc. So the garbage values
depend on many many things.
See the detailed description of the bug and possible ways to fix it
in the kernel bug tracker.
"Bug 59521 - KVM linux guest reads uninitialized pvclock values before
executing rdmsr MSR_KVM_WALL_CLOCK"
I decided to fix it simply returning 0ULL from kvm_clock_read when
kvm clocksource is not initialized yet.
The same as kernel bootstrap CPU doesn on boot stage when kernel
clocksources are not initialized yet.
Signed-off-by: Eugene Batalov
---
I dont' use kernel percpu variables because for each SMP CPU
their contents are copied from the bootstrap CPU. And I don't
think that fixing the value for each SMP CPU is a good style.
If you know a better approach to store the is_pv_clock_ready flags
I am ready to use it.
The patch applies cleanly to
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
I've tested the changes with Ubuntu 13.04 "raring" userspace and
Ubuntu-3.8.0.19-30 kernel tag.
arch/x86/kernel/kvmclock.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 5bedbdd..a6e0af4 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -43,6 +43,9 @@ early_param("no-kvmclock", parse_no_kvmclock);
static struct pvclock_vsyscall_time_info *hv_clock;
static struct pvclock_wall_clock wall_clock;
+/* For each cpu store here a flag which tells whether pvclock is initialized */
+static int __cacheline_aligned_in_smp is_pv_clock_ready[NR_CPUS] = {};
+
/*
* The wallclock is the time of day when we booted. Since then, some time may
* have elapsed since the hypervisor wrote the data. So we try to account for
@@ -84,8 +87,11 @@ static cycle_t kvm_clock_read(void)
preempt_disable_notrace();
cpu = smp_processor_id();
- src = _clock[cpu].pvti;
- ret = pvclock_clocksource_read(src);
+ if (is_pv_clock_ready[cpu]) {
+ src = _clock[cpu].pvti;
+ ret = pvclock_clocksource_read(src);
+ } else
+ ret = 0ULL;
preempt_enable_notrace();
return ret;
}
@@ -168,6 +174,9 @@ int kvm_register_clock(char *txt)
printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n",
cpu, high, low, txt);
+ if (!ret)
+ is_pv_clock_ready[cpu] = 1;
+
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Enable fanotify API by default.
On Sat, Jun 15, 2013 at 06:17:27PM +0200, xypron.g...@gmx.de wrote: > From: Heinrich Schuchardt > > The fanotify interface is the basis for on access malware detection > in the Linux kernel. The development of a prior solution (DazukoFS) > has been stopped therefore. > > Both free (ClamAV) as well as commercial viurs scanners (Sophos > Anti-Virus, AVG) using this interface exist. > > Since kernel version 3.8.0 the implementationof the fanotify inter- > face is errorfree enough to be used on a productive system. > Personally I have been using it for virus scanning on multiple > systems for several months without issues while a developing a > wrapper around ClamAV, see > https://github.com/xypron/skyldav > > A large scale usage of the fanotify interface can only expected if > the API is enabled by default. We only set options to 'default Y' if they are needed in order to keep your machine working properly. Now that this option has been around for a while, changing the default will not affect anyone's machines, as they will not see that change. Why not just work with the distros to enable fanotify, that's where you need this enabled, not here. Those are the majority of users, not kernel developers who pick their own kernel configurations. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] (Was: fput: task_work_add() can fail if the caller has passed exit_task_work())
sorry, forgot to mention... On 06/15, Oleg Nesterov wrote: > > > OT: I don't think that schedule_work() needs to be inside the locked > > region. Scalability improvements beckon! > > Yeees, I thought about this too. > > Performance-wise this can't really help, this case is unlikely. But > I think this change makes this code a bit simpler, so please see 1/3. This is on top of fput-task_work_add-can-fail-if-the-caller-has-passed-exit_task_work-fix.patch it textually depends on the comment block in fput() added by that patch. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] llist: fix/simplify llist_add() and llist_add_batch()
1. This is mostly theoretical, but llist_add*() need ACCESS_ONCE().
Otherwise it is not guaranteed that the first cmpxchg() uses the
same value for old_entry and new_last->next.
2. These helpers cache the result of cmpxchg() and read the initial
value of head->first before the main loop. I do not think this
makes sense. In the likely case cmpxchg() succeeds, otherwise
it doesn't hurt to reload head->first.
I think it would be better to simplify the code and simply read
->first before cmpxchg().
Signed-off-by: Oleg Nesterov
---
include/linux/llist.h | 19 +++
lib/llist.c | 15 +--
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/include/linux/llist.h b/include/linux/llist.h
index a5199f6..3e2b969 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -151,18 +151,13 @@ static inline struct llist_node *llist_next(struct
llist_node *node)
*/
static inline bool llist_add(struct llist_node *new, struct llist_head *head)
{
- struct llist_node *entry, *old_entry;
-
- entry = head->first;
- for (;;) {
- old_entry = entry;
- new->next = entry;
- entry = cmpxchg(>first, old_entry, new);
- if (entry == old_entry)
- break;
- }
-
- return old_entry == NULL;
+ struct llist_node *first;
+
+ do {
+ new->next = first = ACCESS_ONCE(head->first);
+ } while (cmpxchg(>first, first, new) != first);
+
+ return !first;
}
/**
diff --git a/lib/llist.c b/lib/llist.c
index 4a15115..4a70d12 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -39,18 +39,13 @@
bool llist_add_batch(struct llist_node *new_first, struct llist_node *new_last,
struct llist_head *head)
{
- struct llist_node *entry, *old_entry;
+ struct llist_node *first;
- entry = head->first;
- for (;;) {
- old_entry = entry;
- new_last->next = entry;
- entry = cmpxchg(>first, old_entry, new_first);
- if (entry == old_entry)
- break;
- }
+ do {
+ new_last->next = first = ACCESS_ONCE(head->first);
+ } while (cmpxchg(>first, first, new_first) != first);
- return old_entry == NULL;
+ return !first;
}
EXPORT_SYMBOL_GPL(llist_add_batch);
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] llist: llist_add() can use llist_add_batch()
llist_add(new, head) can simply use llist_add_batch(new, new, head),
no need to duplicate the code.
This obviously uninlines llist_add() and to me this is a win. But we
can make llist_add_batch() inline if this is desirable, in this case
gcc can notice that new_first == new_last if the caller is llist_add().
Signed-off-by: Oleg Nesterov
---
include/linux/llist.h | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/include/linux/llist.h b/include/linux/llist.h
index 3e2b969..cdaa7f0 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -142,6 +142,9 @@ static inline struct llist_node *llist_next(struct
llist_node *node)
return node->next;
}
+extern bool llist_add_batch(struct llist_node *new_first,
+ struct llist_node *new_last,
+ struct llist_head *head);
/**
* llist_add - add a new entry
* @new: new entry to be added
@@ -151,13 +154,7 @@ static inline struct llist_node *llist_next(struct
llist_node *node)
*/
static inline bool llist_add(struct llist_node *new, struct llist_head *head)
{
- struct llist_node *first;
-
- do {
- new->next = first = ACCESS_ONCE(head->first);
- } while (cmpxchg(>first, first, new) != first);
-
- return !first;
+ return llist_add_batch(new, new, head);
}
/**
@@ -173,9 +170,6 @@ static inline struct llist_node *llist_del_all(struct
llist_head *head)
return xchg(>first, NULL);
}
-extern bool llist_add_batch(struct llist_node *new_first,
- struct llist_node *new_last,
- struct llist_head *head);
extern struct llist_node *llist_del_first(struct llist_head *head);
#endif /* LLIST_H */
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] fput: turn "list_head delayed_fput_list" into llist_head
fput() and delayed_fput() can use llist and avoid the locking.
This is unlikely path, it is not that this change can improve
the performance, but this way the code looks simpler.
Suggested-by: Andrew Morton
Signed-off-by: Oleg Nesterov
---
fs/file_table.c| 25 ++---
include/linux/fs.h |2 ++
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/fs/file_table.c b/fs/file_table.c
index 3a2bbc5..94b1bfa 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -265,18 +265,15 @@ static void __fput(struct file *file)
mntput(mnt);
}
-static DEFINE_SPINLOCK(delayed_fput_lock);
-static LIST_HEAD(delayed_fput_list);
+static LLIST_HEAD(delayed_fput_list);
static void delayed_fput(struct work_struct *unused)
{
- LIST_HEAD(head);
- spin_lock_irq(_fput_lock);
- list_splice_init(_fput_list, );
- spin_unlock_irq(_fput_lock);
- while (!list_empty()) {
- struct file *f = list_first_entry(, struct file,
f_u.fu_list);
- list_del_init(>f_u.fu_list);
- __fput(f);
+ struct llist_node *node = llist_del_all(_fput_list);
+ struct llist_node *next;
+
+ for (; node; node = next) {
+ next = llist_next(node);
+ __fput(llist_entry(node, struct file, f_u.fu_llist));
}
}
@@ -306,7 +303,6 @@ void fput(struct file *file)
{
if (atomic_long_dec_and_test(>f_count)) {
struct task_struct *task = current;
- unsigned long flags;
file_sb_list_del(file);
if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
@@ -320,10 +316,9 @@ void fput(struct file *file)
* fput to avoid leaking *file.
*/
}
- spin_lock_irqsave(_fput_lock, flags);
- list_add(>f_u.fu_list, _fput_list);
- schedule_work(_fput_work);
- spin_unlock_irqrestore(_fput_lock, flags);
+
+ if (llist_add(>f_u.fu_llist, _fput_list))
+ schedule_work(_fput_work);
}
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 43db02e..8a60d99 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -767,6 +768,7 @@ struct file {
*/
union {
struct list_headfu_list;
+ struct llist_node fu_llist;
struct rcu_head fu_rcuhead;
} f_u;
struct path f_path;
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] (Was: fput: task_work_add() can fail if the caller has passed exit_task_work())
On 06/14, Andrew Morton wrote:
>
> On Fri, 14 Jun 2013 21:09:47 +0200 Oleg Nesterov wrote:
>
> > + if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
> > + init_task_work(>f_u.fu_rcuhead, fput);
> > + if (!task_work_add(task, >f_u.fu_rcuhead, true))
> > + return;
>
> A comment here would be useful, explaining the circumstances under
> which we fall through to the delayed fput.
Thanks!
> This is particularly needed
> because kernel/task_work.c is such undocumented crap.
It seems that you are trying to force me to make the doc patch ;)
OK, I'll try. task_work.c needs a couple of cosmetic cleanups anyway.
> > + spin_lock_irqsave(_fput_lock, flags);
> > + list_add(>f_u.fu_list, _fput_list);
> > + schedule_work(_fput_work);
> > + spin_unlock_irqrestore(_fput_lock, flags);
>
> OT: I don't think that schedule_work() needs to be inside the locked
> region. Scalability improvements beckon!
Yeees, I thought about this too.
Performance-wise this can't really help, this case is unlikely. But
I think this change makes this code a bit simpler, so please see 1/3.
2/3 fixes the (theoretical) bug in llist_add() and imho cleanups the
code.
3/3 comes as a separate change because I do not want to argue if
someone dislike the non-inline llist_add(). But once again, we can
make llist_add_batch() inline, and I believe it is never good to
duplicate the code even if it is simple.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: SoC fixes for 3.10-rc
Hi Linus,
These are a little later than I planned on since I got caught up with handling
merges for 3.11 most of the week. Details below.
Thanks,
-Olof
The following changes since commit 090878aa951628143f40a1acc19ec074a5ae9200:
Merge tag 'mxs-fixes-3.10' of git://git.linaro.org/people/shawnguo/linux-2.6
into fixes (2013-06-07 18:19:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/fixes-for-linus
for you to fetch changes up to 323226bbb3d865af12644d66df2b7f161adf51c7:
Merge tag 'fixes-3.10-4' of git://git.infradead.org/users/jcooper/linux into
fixes (2013-06-11 17:05:56 -0700)
ARM: SoC fixes for 3.10-rc
Another week, another batch of fixes for arm-soc platforms.
Again, nothing controversial. A few more than would be ideal, but all
are valid fixes. In particular the prima2 panic patch is critical since
it fixes a problem where multiplatform kernels panic on all but prima2
hardware.
Haojian Zhuang (1):
ARM: prima2: fix incorrect panic usage
Jean-Philippe Francois (1):
ARM: omap3: clock: fix wrong container_of in clock36xx.c
Kevin Hilman (1):
ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line
Lars Poeschel (1):
ARM: dts: AM33xx: Fix properties on gpmc node
Nicolas Schichan (1):
ARM: Kirkwood: handle mv88f6282 cpu in __kirkwood_variant().
Olof Johansson (2):
Merge tag 'omap-for-v3.10/fixes-v3.10-rc4' of
git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'fixes-3.10-4' of git://git.infradead.org/users/jcooper/linux
into fixes
Suman Anna (1):
ARM: dts: OMAP5: Fix missing PWM capability to timer nodes
Thomas Petazzoni (2):
arm: omap2: fix AM33xx hwmod infos for UART2
arm: mvebu: armada-xp-{gp,openblocks-ax3-4}: specify PCIe range
Tomasz Figa (1):
ARM: SAMSUNG: pm: Adjust for pinctrl- and DT-enabled platforms
Tony Lindgren (3):
ARM: OMAP3: Fix iva2_pwrdm settings for 3703
Merge branch 'dts-fixes-for-3.10' of
git://git.kernel.org/.../bcousson/linux-omap-dt into omap-for-v3.10/fixes
Merge tag 'omap-fixes-b-for-3.10-rc' of
git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.10/fixes
arch/arm/boot/dts/am33xx.dtsi| 4 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 5 +++--
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++--
arch/arm/boot/dts/omap4-panda-common.dtsi| 20
arch/arm/boot/dts/omap4-sdp.dts | 20
arch/arm/boot/dts/omap5.dtsi | 3 +++
arch/arm/mach-kirkwood/mpp.c | 5 +++--
arch/arm/mach-omap2/clock36xx.c | 18 +-
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 9 -
arch/arm/mach-omap2/pm34xx.c | 6 --
arch/arm/mach-prima2/pm.c| 6 --
arch/arm/mach-prima2/rstc.c | 6 --
arch/arm/plat-samsung/pm.c | 18 +-
13 files changed, 96 insertions(+), 29 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/31] MIPS: Quit exposing Kconfig symbols in uapi headers.
Il 07/06/2013 19:03, David Daney ha scritto:
> From: David Daney
>
> The kernel's struct pt_regs has many fields conditional on various
> Kconfig variables, we cannot be exporting this garbage to user-space.
>
> Move the kernel's definition to asm/ptrace.h, and put a uapi only
> version in uapi/asm/ptrace.h gated by #ifndef __KERNEL__
>
> Signed-off-by: David Daney
> ---
> arch/mips/include/asm/ptrace.h | 32
> arch/mips/include/uapi/asm/ptrace.h | 17 ++---
> 2 files changed, 34 insertions(+), 15 deletions(-)
>
> diff --git a/arch/mips/include/asm/ptrace.h b/arch/mips/include/asm/ptrace.h
> index a3186f2..5e6cd09 100644
> --- a/arch/mips/include/asm/ptrace.h
> +++ b/arch/mips/include/asm/ptrace.h
> @@ -16,6 +16,38 @@
> #include
> #include
>
> +/*
> + * This struct defines the way the registers are stored on the stack during a
> + * system call/exception. As usual the registers k0/k1 aren't being saved.
> + */
> +struct pt_regs {
> +#ifdef CONFIG_32BIT
> + /* Pad bytes for argument save space on the stack. */
> + unsigned long pad0[6];
> +#endif
> +
> + /* Saved main processor registers. */
> + unsigned long regs[32];
> +
> + /* Saved special registers. */
> + unsigned long cp0_status;
> + unsigned long hi;
> + unsigned long lo;
> +#ifdef CONFIG_CPU_HAS_SMARTMIPS
> + unsigned long acx;
> +#endif
> + unsigned long cp0_badvaddr;
> + unsigned long cp0_cause;
> + unsigned long cp0_epc;
> +#ifdef CONFIG_MIPS_MT_SMTC
> + unsigned long cp0_tcstatus;
> +#endif /* CONFIG_MIPS_MT_SMTC */
> +#ifdef CONFIG_CPU_CAVIUM_OCTEON
> + unsigned long long mpl[3];/* MTM{0,1,2} */
> + unsigned long long mtp[3];/* MTP{0,1,2} */
> +#endif
> +} __aligned(8);
> +
> struct task_struct;
>
> extern int ptrace_getregs(struct task_struct *child, __s64 __user *data);
> diff --git a/arch/mips/include/uapi/asm/ptrace.h
> b/arch/mips/include/uapi/asm/ptrace.h
> index 4d58d84..b26f7e3 100644
> --- a/arch/mips/include/uapi/asm/ptrace.h
> +++ b/arch/mips/include/uapi/asm/ptrace.h
> @@ -22,16 +22,12 @@
> #define DSP_CONTROL 77
> #define ACX 78
>
> +#ifndef __KERNEL__
> /*
> * This struct defines the way the registers are stored on the stack during a
> * system call/exception. As usual the registers k0/k1 aren't being saved.
> */
> struct pt_regs {
> -#ifdef CONFIG_32BIT
> - /* Pad bytes for argument save space on the stack. */
> - unsigned long pad0[6];
> -#endif
> -
Out of curiosity, how has this ever worked (and how will this work) on
32-bit arches? :) I can see that maybe no one uses pt_regs beyond .lo,
but these are at the beginning. Maybe for the uapi version you can use
the __mips__ preprocessor symbol?
Paolo
> /* Saved main processor registers. */
> unsigned long regs[32];
>
> @@ -39,20 +35,11 @@ struct pt_regs {
> unsigned long cp0_status;
> unsigned long hi;
> unsigned long lo;
> -#ifdef CONFIG_CPU_HAS_SMARTMIPS
> - unsigned long acx;
> -#endif
> unsigned long cp0_badvaddr;
> unsigned long cp0_cause;
> unsigned long cp0_epc;
> -#ifdef CONFIG_MIPS_MT_SMTC
> - unsigned long cp0_tcstatus;
> -#endif /* CONFIG_MIPS_MT_SMTC */
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> - unsigned long long mpl[3];/* MTM{0,1,2} */
> - unsigned long long mtp[3];/* MTP{0,1,2} */
> -#endif
> } __attribute__ ((aligned (8)));
> +#endif /* __KERNEL__ */
>
> /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
> #define PTRACE_GETREGS 12
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: unable to handle kernel NULL pointer dereference at 0000000000000040
on Sat, 15 Jun 2013 11:08:47 +0300, Ming Lei wrote: On Sat, Jun 15, 2013 at 2:30 PM, Guenter Roeck wrote: On Sat, Jun 15, 2013 at 10:32:14AM +0800, Ming Lei wrote: On Sat, Jun 15, 2013 at 1:07 AM, nirinA raseliarison wrote: > patch applied and no longer have the bug message when i > reboot and wake up the ethernet controller. I am wondering if Guenter's patch can fix the race really, but I'd like to see Guenter's explanation on his patch. The race should be caused by below: - request timeout triggered by internal timer - user space aborts the requests before the line in _request_firmware_load() fw_priv->buf = NULL which is run in timeout path - then the abort() called from firmware_loading_store() may use a freed fw buf since the timeout path will free the fw buffer. Considered clearing 'fw_priv->buf' in _request_firmware_load()() isn't protected by fw_lock now, so Guenter's patch can't avoid the race entirely. I agree; my patch only protects one specific path, and was based on the observation that access to fw_priv->buf is protected elsewhwere in the code. My suspicion was that fw_priv->buf was freed while waiting for the mutex in firmware_loading_store(). Your patch is more comprehensive. OK, thanks for your reply. I will post out one version for merge, and this one moves the "fw_priv->buf = NULL;" into fw_load_abort() for simplifying change. this is just to let you know that i've tested Ming Lei's latest patch. thank you very much for the fix and the explanation. -- nirinA -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: i2c: ths7303: remove unused member driver_data
From: "Lad, Prabhakar"
This patch removes the driver_data member from ths7303_state structure.
The driver_data member was intended to differentiate between ths7303 and
ths7353 chip and get the g_chip_ident, But as of now g_chip_ident is
obsolete, so there is no need of driver_data.
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/ths7303.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index 2e17abc..0a2dacb 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -38,7 +38,6 @@ struct ths7303_state {
struct v4l2_bt_timings bt;
int std_id;
int stream_on;
- int driver_data;
};
enum ths7303_filter_mode {
@@ -355,9 +354,6 @@ static int ths7303_probe(struct i2c_client *client,
sd = >sd;
v4l2_i2c_subdev_init(sd, client, _ops);
- /* store the driver data to differntiate the chip */
- state->driver_data = (int)id->driver_data;
-
/* set to default 480I_576I filter mode */
if (ths7303_setval(sd, THS7303_FILTER_MODE_480I_576I) < 0) {
v4l_err(client, "Setting to 480I_576I filter mode failed!\n");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] intel-iommu: Fix leaks in pagetable freeing
At best the current code only seems to free the leaf pagetables and
the root. If you're unlucky enough to have a large gap (like any
QEMU guest with more than 3G of memory), only the first chunk of leaf
pagetables are freed (plus the root). This is a massive memory leak.
This patch re-writes the pagetable freeing function to use a
recursive algorithm and manages to not only free all the pagetables,
but does it without any apparent performance loss versus the current
broken version.
Signed-off-by: Alex Williamson
Cc: sta...@vger.kernel.org
---
Suggesting for stable, would like to see some soak time, but it's
hard to imagine this being any worse than the current code.
This likely also affects device domains, but the current code does
ok at freeing individual leaf pagetables and driver domains would
only get a full pruning if the driver or device is removed.
Some test programs:
https://github.com/awilliam/tests/blob/master/kvm-huge-guest-test.c
https://github.com/awilliam/tests/blob/master/vfio-huge-guest-test.c
Both of these simulate a large guest on a small host system. They
mmap 4G of memory and map it across a large address space just like
QEMU would (aside from re-using the same mmap across multiple IOVAs).
On existing code the vfio version (w/o a KVM memory slot limit) will
leak over 1G of pagetables per run.
drivers/iommu/intel-iommu.c | 72 +--
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index eec0d3e..15e9b57 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -890,56 +890,54 @@ static int dma_pte_clear_range(struct dmar_domain *domain,
return order;
}
+static void dma_pte_free_level(struct dmar_domain *domain, int level,
+ struct dma_pte *pte, unsigned long pfn,
+ unsigned long start_pfn, unsigned long last_pfn)
+{
+ pfn = max(start_pfn, pfn);
+ pte = [pfn_level_offset(pfn, level)];
+
+ do {
+ unsigned long level_pfn;
+ struct dma_pte *level_pte;
+
+ if (!dma_pte_present(pte) || dma_pte_superpage(pte))
+ goto next;
+
+ level_pfn = pfn & level_mask(level - 1);
+ level_pte = phys_to_virt(dma_pte_addr(pte));
+
+ if (level > 2)
+ dma_pte_free_level(domain, level - 1, level_pte,
+ level_pfn, start_pfn, last_pfn);
+
+ /* If range covers entire pagetable, free it */
+ if (!(start_pfn > level_pfn ||
+ last_pfn < level_pfn + level_size(level))) {
+ dma_clear_pte(pte);
+ domain_flush_cache(domain, pte, sizeof(*pte));
+ free_pgtable_page(level_pte);
+ }
+next:
+ pfn += level_size(level);
+ } while (!first_pte_in_page(++pte) && pfn <= last_pfn);
+}
+
/* free page table pages. last level pte should already be cleared */
static void dma_pte_free_pagetable(struct dmar_domain *domain,
unsigned long start_pfn,
unsigned long last_pfn)
{
int addr_width = agaw_to_width(domain->agaw) - VTD_PAGE_SHIFT;
- struct dma_pte *first_pte, *pte;
- int total = agaw_to_level(domain->agaw);
- int level;
- unsigned long tmp;
- int large_page = 2;
BUG_ON(addr_width < BITS_PER_LONG && start_pfn >> addr_width);
BUG_ON(addr_width < BITS_PER_LONG && last_pfn >> addr_width);
BUG_ON(start_pfn > last_pfn);
/* We don't need lock here; nobody else touches the iova range */
- level = 2;
- while (level <= total) {
- tmp = align_to_level(start_pfn, level);
-
- /* If we can't even clear one PTE at this level, we're done */
- if (tmp + level_size(level) - 1 > last_pfn)
- return;
-
- do {
- large_page = level;
- first_pte = pte = dma_pfn_level_pte(domain, tmp, level,
_page);
- if (large_page > level)
- level = large_page + 1;
- if (!pte) {
- tmp = align_to_level(tmp + 1, level + 1);
- continue;
- }
- do {
- if (dma_pte_present(pte)) {
-
free_pgtable_page(phys_to_virt(dma_pte_addr(pte)));
- dma_clear_pte(pte);
- }
- pte++;
- tmp += level_size(level);
- } while (!first_pte_in_page(pte) &&
-tmp +
[PATCH 1/1] Enable fanotify API by default.
From: Heinrich Schuchardt The fanotify interface is the basis for on access malware detection in the Linux kernel. The development of a prior solution (DazukoFS) has been stopped therefore. Both free (ClamAV) as well as commercial viurs scanners (Sophos Anti-Virus, AVG) using this interface exist. Since kernel version 3.8.0 the implementationof the fanotify inter- face is errorfree enough to be used on a productive system. Personally I have been using it for virus scanning on multiple systems for several months without issues while a developing a wrapper around ClamAV, see https://github.com/xypron/skyldav A large scale usage of the fanotify interface can only expected if the API is enabled by default. Hence I recommend to change the Kconfig file accordingly. Signed-off-by: Heinrich Schuchardt --- fs/notify/fanotify/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/notify/fanotify/Kconfig b/fs/notify/fanotify/Kconfig index e5f911b..929ad74 100644 --- a/fs/notify/fanotify/Kconfig +++ b/fs/notify/fanotify/Kconfig @@ -2,7 +2,7 @@ config FANOTIFY bool "Filesystem wide access notification" select FSNOTIFY select ANON_INODES - default n + default y ---help--- Say Y here to enable fanotify support. fanotify is a file access notification system which differs from inotify in that it sends @@ -15,7 +15,7 @@ config FANOTIFY_ACCESS_PERMISSIONS bool "fanotify permissions checking" depends on FANOTIFY depends on SECURITY - default n + default y ---help--- Say Y here is you want fanotify listeners to be able to make permissions decisions concerning filesystem events. This is used by some fanotify @@ -23,4 +23,4 @@ config FANOTIFY_ACCESS_PERMISSIONS use those files. This is used by some anti-malware vendors and by some hierarchical storage managent systems. - If unsure, say N. + If unsure, say Y. -- 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/
Fwd: bug report about acpiphp
I would like to report a bug about the module acpiphp. I don't know if this is the right place, if it isn't please tell me where I should write and I will do it. description: docking station hotplug working on 3.5.0 kernel but not in previous and next kernel releases hardware: sony vaio serie z SVZ1311C5E + Docking station VGP-PRZ20A distro: Ubuntu precise, kernels compiled from the source in kernel.org The problem is about connecting the docking station after the boot. with kernel 3.5.0: when I connect the docking station I can see the following log lines (dmesg): [ 2442.046921] acpiphp: Slot [1-1] registered [ 2442.046945] acpiphp: Slot [2] registered [ 2442.046968] acpiphp: Slot [3] registered [ 2442.047056] acpiphp: Slot [1-2] registered [ 2442.047066] acpiphp_glue: sibling found, but _SUN doesn't match! [ 2442.047169] acpiphp: Slot [1-3] registered [ 2442.047229] acpiphp: Slot [1-4] registered [ 2442.047300] acpiphp: Slot [1-5] registered after that all the devices are available in the system. I can use the external network, the bluray device, and the usb ports available in the docking station. if I unload the acpiphp module the hotplug doesn't work, meaning no log lines and devices not usable. with any other kernel (I tried also with 3.10rc5): when I connect the docking station I cannot see the log lines specified above, and the devices are not available. I tried with and without acpiphp loaded. I didn't tried with other 3.5 kernel versions. I tried with 3.7 and 3.8 and it is not working If I connect the docking station before the boot with a non 3.5.0 kernel and I unplug it I can continue to see the devices available but of course not working. Thank you for your support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
On Sat, Jun 15, 2013 at 08:29:15PM +0800, Aaron Lu wrote: > On 06/15/2013 12:19 PM, Matthew Garrett wrote: > > The vendor will presumably have tested that backlight control works - if > > the GPU driver uses the ACPI interface and backlight control is broken, > > then the vendor would fix it. > > I don't think GPU driver uses ACPI interface, that's why for some > systems, ACPI interface is broken while the GPU's is not. On systems where the ACPI interface is broken, the GPU driver clearly doesn't use the ACPI interface. As yet, we don't know if that's always true, though. > > Sure, but it still requires the replacement of existing userspace. We > > need to fix the problem with existing userspace, too. > > Yes. The problem is two way. First, some of the backlight interface > privoder module provides a broken interface; Two, the userspace picked a > broken interface while there are usable ones. For example, in the win8 > thinkpad case, the ACPI video driver provides broken interface and the > GPU driver provides usable interface, but userspace choose ACPI video's > interface. To make things complicated, if we make the broken interface > disappear in ACPI video module, then the platform driver thinkpad_acpi > will start to provide another broken interface. I have to say, solve it > in the GPU code is a clever way, it's just a little weird to me for a > broken interface to be blacklisted, we have to do it in another module, > not the broken module itself. The ACPI driver has no way of making this kind of policy decision. The GPU driver does. > > No, I think we need to fix the bugs that currently require users to pass > > options. > > For ACPI video driver, since it relies on firmware to do the right thing, > if the functionality is broken, then it is, there is hardly anything we > can do...(not always, we can quirk in some cases, but there are cases we > can do nothing). In this case, we can: > 1 Ask user to add acpi_backlight=vendor, so that ACPI video driver will > not create backlight interface and userspace will not pick it; > 2 Add that model in DMI table in video_detect.c, eliminating the need for > that command line; > 3 Add that model in DMI table in another module, let that module > unregister backlight interface provided by ACPI video as is done in > acer-wmi, asus-wmi, and i915 in this case; > 3 Use the backlight section in xorg.conf to make X uses another > backlight interface. This may not work for distros that use > gsd-backlight-helper, which always prefers firmware. > > Which one do you prefer? I'd prefer to figure out how it works in Windows and implement it the same way. > > How do these machines work under Windows? Until we know the answer to > > that, we don't know what the correct way to handle the problem is under > > Linux. > > Do you mean we need to understand Windows behavior so that we can > decide where to place the code to do the backlight management thing? > So for win8 case, we know MS will use GPU driver to do backlight > control, all this means to me is, ACPI video's and platform driver's > interface are more likely broken on those systems, but it doesn't > qualify why Linux' GPU driver should do the decision, it's not that the > GPU driver can poke some GPU register and then decide oh, this model > does not have working ACPI backlight interface. As this patch shows, we > make the decision by OSI, which is not specific to GPU driver. Sure it is - for all we know there's a value in the opregion space that tells the Intel GPU driver which interface we should be using. We don't know because Intel haven't released a version of the opregion driver newer than 2007. It may be that all Windows 8 GPU drivers use the GPU backlight control registers directly and never use any firmware interface, but right now we simply don't know that. All we can do is look at the existing cases we have and say that it appears that Intel graphics systems don't use the ACPI interface. Anything more than that requires more evidence. > BTW, I don't think any module knows something better than another > module, all quirk logic and DMI entry we currently have in Linux are > got by user's feedback(bug reports), it doesn't seem to me some module > is natrually the one that should make this decision. Or do I miss > something? The GPU driver makes the policy decision under Windows 8, so it's the natural place to make this decision on Windows 8 systems. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/14] locks: don't walk inode->i_flock list in locks_show
On 06/15/2013 07:05 AM, Jeff Layton wrote: On Fri, 14 Jun 2013 07:52:44 -0400 Simo wrote: On 06/13/2013 04:26 PM, Jeff Layton wrote: The only real solution I can think of is to put flock locks into the blocked_list/blocked_hash too, or maybe giving them a simple hlist to sit on. I'll fix that up in the next iteration. It'll probably make flock() tests run slower, but such is the cost of preserving this procfile... How hard would it be to make the procfile stuff optional ? So that those that need performance can decide to not use it ? Maybe even something that can be disabled at run time ? Not just compile time. (re-adding back the cc lists...) It'd be tricky, especially if you want to do it at runtime. The procfile itself is not a problem per-se. The real problem is the tracking you have to do in order to eventually present the procfile. So a boot-time or compile-time switch might be reasonable, but a runtime switch will probably never really be. Just to be clear, I meant for a switch to turn it off at runtime, I understand very well that it would be way too hard to turn on at runtime. But killing the perf problem might be desirable on a system you cannot just reboot. I have a new patchset that I'm testing now though that should address Bruce's concerns about iterating over that global list. So far, it seems to be at least as fast as the latest patchset I posted. It makes the (spin)locking a bit more complex, but hopefully I can document this well enough that it's not a great concern. Stay tuned... Thanks Jeff, this is very valuable work. Simo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: add AM33XX MMC support
Hi, On Fri, Jun 14, 2013 at 06:43:51PM -0500, Joel A Fernandes wrote: > > > >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard > > > >> smoke test. My EVM is intermittent now so trying to coax it to power > > up > > > >> to reverify. > > > >> > > > > > > > > Matt, > > > > > > > > Your branch is working for me, I tested it on EVM. Not sure what is > > wrong with manual rebasing > > > > I did yesterday. I will try to nail-down root-cause here. > > > > > > > > And you can submit the next version fixing the comments I have given. > > > > > > The only comment I could find in the whole discussion was adding of > > > the interrupts property. I tested I don't have any problem booting > > > with Matt's patch, without having the interrupts property. > > > > might very well be, but we want to figure out why adding "intrrupts" > > causes issues. Why does it have to come through hwmod ? You might have > > uncovered a real problem which needs fixing. Besides, at the end of the > > > No actually I think I wasn't very descriptive in my post. There is no > problem here. Whether it comes from DT or not, it works in both cases . (I > haven't tried adding interrupt node to dts but what I gathered from > Vaibhav's post is that it works also when added to dts) > > But I can revisit Vaibhav's suggestion of adding it to dts for completeness > sake. My tree currently works and picks up the interrupt info from hwmod. I > just didn't see any activity on this thread for a while so I thought of > enquiring it was ok to pull it in for the 3.11 merge window or if the > consensus was that interrupt node be added to dts even though it works > without it. fair enough, then let's just add those interrupts to hwmod which will, eventually, let us drop all of that data from hwmod. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] Re: [Patch] MCE, APEI: Don't enable CMCI when Firmware First mode is set in
On Fri, Jun 14, 2013 at 11:47:21PM +0530, Naveen N. Rao wrote:
> HEST for corrected machine checks
>
> Here's a patch that implements this technique. If the firmware advertises
> support for firmware first mode in the CMC structure, we disable CMCI and
> polling for all the MCA banks listed in the CMC structure.
Yeah, this commit message needs a bit massaging. Don't be afraid to be
more verbose than you feel is necessary. :-)
> Signed-off-by: Naveen N. Rao
> ---
> arch/x86/include/asm/mce.h |3 ++
> arch/x86/kernel/cpu/mcheck/mce_intel.c | 38 +++
> drivers/acpi/apei/hest.c | 39
>
> 3 files changed, 80 insertions(+)
>
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index fa5f71e..9c91683 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -188,6 +188,9 @@ extern void register_mce_write_callback(ssize_t
> (*)(struct file *filp,
> const char __user *ubuf,
> size_t usize, loff_t *off));
>
> +/* Disable CMCI/polling for MCA bank claimed by firmware */
> +extern void mce_disable_bank(int bank);
> +
> /*
> * Exception handler
> */
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index ae1697c..bc0307d 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -26,6 +26,9 @@
>
> static DEFINE_PER_CPU(mce_banks_t, mce_banks_owned);
>
> +/* MCA banks controlled through firmware first */
> +static mce_banks_t mce_banks_disabled;
> +
> /*
> * cmci_discover_lock protects against parallel discovery attempts
> * which could race against each other.
> @@ -191,6 +194,10 @@ static void cmci_discover(int banks)
> if (test_bit(i, owned))
> continue;
>
> + /* Skip banks in firmware first mode */
> + if (test_bit(i, mce_banks_disabled))
> + continue;
> +
> rdmsrl(MSR_IA32_MCx_CTL2(i), val);
>
> /* Already owned by someone else? */
> @@ -315,6 +322,37 @@ void cmci_reenable(void)
> cmci_discover(banks);
> }
>
> +static void cmci_disable_bank(void *arg)
> +{
> + int banks;
> + unsigned long flags;
> + u64 val;
> + int bank = *((int *)arg);
> +
> + /* Ensure we don't poll this bank */
> + __clear_bit(bank, __get_cpu_var(mce_poll_banks));
> +
> + if (!cmci_supported())
> + return;
Hmm, so if CMCI is not supported, you just disabled polling of this bank
and returned here. Not good.
> +
> + raw_spin_lock_irqsave(_discover_lock, flags);
> +
> + /* Disable CMCI */
> + rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
> + val &= ~MCI_CTL2_CMCI_EN;
> + wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
> +
> + __clear_bit(bank, __get_cpu_var(mce_banks_owned));
> +
> + raw_spin_unlock_irqrestore(_discover_lock, flags);
Almost the exact sequence is also in cmci_clear(). How about a static
function called __cmci_disable_bank which does that and the other
functions call it?
> +}
> +
> +void mce_disable_bank(int bank)
> +{
> + set_bit(bank, mce_banks_disabled);
> + on_each_cpu(cmci_disable_bank, , 1);
> +}
> +
> static void intel_init_cmci(void)
> {
> int banks;
> diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
> index f5ef5d5..765d8bf 100644
> --- a/drivers/acpi/apei/hest.c
> +++ b/drivers/acpi/apei/hest.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include "apei-internal.h"
>
> @@ -121,6 +122,42 @@ int apei_hest_parse(apei_hest_func_t func, void *data)
> }
> EXPORT_SYMBOL_GPL(apei_hest_parse);
>
> +/*
> + * Check if firmware advertises firmware first mode. We need FF bit to be set
> + * along with a set of MC banks which work in FF mode.
> + */
> +static int __init hest_parse_cmc(struct acpi_hest_header *hest_hdr, void
> *data)
> +{
> + int i;
> + struct acpi_hest_ia_corrected *cmc;
> + struct acpi_hest_ia_error_bank *mc_bank;
> +
> + if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
> + return 0;
> +
> + if (!((struct acpi_hest_generic *)hest_hdr)->enabled)
> + return 0;
> +
> + cmc = (struct acpi_hest_ia_corrected *)hest_hdr;
There is some crazy casting going on here: hest_hdr can be struct
acpi_hest_generic and struct acpi_hest_ia_corrected.
Since the ->enabled field overlaps in both structs and you want only it
as a struct acpi_hest_generic, and want the cmc later, why don't you do
this:
struct acpi_hest_ia_corrected *cmc = (struct acpi_hest_ia_corrected
*)hest_hdr;
if (!cmc->enabled)
...
Then this below:
> + if (!(cmc->flags & ACPI_HEST_FIRMWARE_FIRST))
> + return 0;
and so on... It should simplify the code a bit and drop the fun games
with
[PATCH v2 15/20] n_tty: Factor ISTRIP and IUCLC receive_buf into separate fn
Convert to modal receive_buf processing; factor char receive
processing for unusual termios settings out of normal per-char
i/o path.
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 3e96828..17cb70e 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1416,16 +1416,6 @@ static inline void n_tty_receive_char(struct tty_struct
*tty, unsigned char c)
struct n_tty_data *ldata = tty->disc_data;
int parmrk;
- if (I_ISTRIP(tty))
- c &= 0x7f;
- if (I_IUCLC(tty) && L_IEXTEN(tty))
- c = tolower(c);
-
- if (L_EXTPROC(tty)) {
- put_tty_queue(c, ldata);
- return;
- }
-
/*
* If the previous character was LNEXT, or we know that this
* character is not one of the characters that we'll have to
@@ -1583,9 +1573,34 @@ n_tty_receive_buf_closing(struct tty_struct *tty, const
unsigned char *cp,
static void
n_tty_receive_buf_standard(struct tty_struct *tty, const unsigned char *cp,
- char *fp, int count)
+ char *fp, int count)
+{
+ char flag = TTY_NORMAL;
+
+ while (count--) {
+ if (fp)
+ flag = *fp++;
+ if (likely(flag == TTY_NORMAL)) {
+ unsigned char c = *cp++;
+
+ if (I_ISTRIP(tty))
+ c &= 0x7f;
+ if (I_IUCLC(tty) && L_IEXTEN(tty))
+ c = tolower(c);
+ if (L_EXTPROC(tty)) {
+ put_tty_queue(c, ldata);
+ continue;
+ }
+ n_tty_receive_char(tty, c);
+ } else
+ n_tty_receive_char_flagged(tty, *cp++, flag);
+ }
+}
+
+static void
+n_tty_receive_buf_fast(struct tty_struct *tty, const unsigned char *cp,
+ char *fp, int count)
{
- struct n_tty_data *ldata = tty->disc_data;
char flag = TTY_NORMAL;
while (count--) {
@@ -1611,7 +1626,10 @@ static void __receive_buf(struct tty_struct *tty, const
unsigned char *cp,
else if (tty->closing && !L_EXTPROC(tty))
n_tty_receive_buf_closing(tty, cp, fp, count);
else {
- n_tty_receive_buf_standard(tty, cp, fp, count);
+ if (!preops)
+ n_tty_receive_buf_fast(tty, cp, fp, count);
+ else
+ n_tty_receive_buf_standard(tty, cp, fp, count);
flush_echoes(tty);
if (tty->ops->flush_chars)
--
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/
[PATCH v2 16/20] n_tty: Factor PARMRK from normal per-char i/o
Handle PARMRK processing on the slow per-char i/o path.
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 45 +++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 17cb70e..40f 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1456,6 +1456,47 @@ static inline void n_tty_receive_char(struct tty_struct
*tty, unsigned char c)
}
static inline void
+n_tty_receive_char_fast(struct tty_struct *tty, unsigned char c)
+{
+ struct n_tty_data *ldata = tty->disc_data;
+
+ /*
+* If the previous character was LNEXT, or we know that this
+* character is not one of the characters that we'll have to
+* handle specially, do shortcut processing to speed things
+* up.
+*/
+ if (!test_bit(c, ldata->char_map) || ldata->lnext) {
+ ldata->lnext = 0;
+
+ if (tty->stopped && !tty->flow_stopped && I_IXON(tty) &&
+ I_IXANY(tty)) {
+ start_tty(tty);
+ process_echoes(tty);
+ }
+
+ if (read_cnt(ldata) >= (N_TTY_BUF_SIZE - 1)) {
+ /* beep if no space */
+ if (L_ECHO(tty))
+ process_output('\a', tty);
+ return;
+ }
+ if (L_ECHO(tty)) {
+ finish_erasing(ldata);
+ /* Record the column of first canon char. */
+ if (ldata->canon_head == ldata->read_head)
+ echo_set_canon_col(ldata);
+ echo_char(c, tty);
+ commit_echoes(tty);
+ }
+ put_tty_queue(c, ldata);
+ return;
+ }
+
+ n_tty_receive_char_special(tty, c);
+}
+
+static inline void
n_tty_receive_char_closing(struct tty_struct *tty, unsigned char c)
{
if (I_ISTRIP(tty))
@@ -1607,7 +1648,7 @@ n_tty_receive_buf_fast(struct tty_struct *tty, const
unsigned char *cp,
if (fp)
flag = *fp++;
if (likely(flag == TTY_NORMAL))
- n_tty_receive_char(tty, *cp++);
+ n_tty_receive_char_fast(tty, *cp++);
else
n_tty_receive_char_flagged(tty, *cp++, flag);
}
@@ -1626,7 +1667,7 @@ static void __receive_buf(struct tty_struct *tty, const
unsigned char *cp,
else if (tty->closing && !L_EXTPROC(tty))
n_tty_receive_buf_closing(tty, cp, fp, count);
else {
- if (!preops)
+ if (!preops && !I_PARMRK(tty))
n_tty_receive_buf_fast(tty, cp, fp, count);
else
n_tty_receive_buf_standard(tty, cp, fp, count);
--
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/
[PATCH v2 20/20] tty: Remove extra wakeup from pty write() path
Acquiring the write_wait queue spin lock now accounts for the largest
slice of cpu time on the tty write path. Two factors contribute to
this situation; a overly-pessimistic line discipline write loop which
_always_ sets up a wait loop even if i/o will immediately succeed, and
on ptys, a wakeup storm from reads and writes.
Writer wakeup does not need to be performed by the pty driver.
Firstly, since the actual i/o is performed within the write, the
line discipline write loop will continue while space remains in
the flip buffers. Secondly, when space becomes avail in the
line discipline receive buffer (and thus also in the flip buffers),
the pty unthrottle re-wakes the writer (non-flow-controlled line
disciplines unconditionally unthrottle the driver when data is
received). Thus, existing in-kernel i/o is guaranteed to advance.
Finally, writer wakeup occurs at the conclusion of the line discipline
write (in tty_write_unlock()). This guarantees that any user-space write
waiters are woken to continue additional i/o.
Signed-off-by: Peter Hurley
---
drivers/tty/pty.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 0634dd9..b9bc5be 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -121,10 +121,8 @@ static int pty_write(struct tty_struct *tty, const
unsigned char *buf, int c)
/* Stuff the data into the input queue of the other end */
c = tty_insert_flip_string(to->port, buf, c);
/* And shovel */
- if (c) {
+ if (c)
tty_flip_buffer_push(to->port);
- tty_wakeup(tty);
- }
}
return c;
}
--
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/
[PATCH v2 14/20] n_tty: Split n_tty_receive_char()
Factor 'special' per-char processing into standalone fn,
n_tty_receive_char_special(), which handles processing for chars
marked in the char_map.
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 103
1 file changed, 56 insertions(+), 47 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 1f21c97..3e96828 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1253,57 +1253,12 @@ n_tty_receive_signal_char(struct tty_struct *tty, int
signal, unsigned char c)
* otherwise, publishes read_head via put_tty_queue()
*/
-static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
+static void
+n_tty_receive_char_special(struct tty_struct *tty, unsigned char c)
{
struct n_tty_data *ldata = tty->disc_data;
int parmrk;
- if (I_ISTRIP(tty))
- c &= 0x7f;
- if (I_IUCLC(tty) && L_IEXTEN(tty))
- c = tolower(c);
-
- if (L_EXTPROC(tty)) {
- put_tty_queue(c, ldata);
- return;
- }
-
- /*
-* If the previous character was LNEXT, or we know that this
-* character is not one of the characters that we'll have to
-* handle specially, do shortcut processing to speed things
-* up.
-*/
- if (!test_bit(c, ldata->char_map) || ldata->lnext) {
- ldata->lnext = 0;
-
- if (tty->stopped && !tty->flow_stopped && I_IXON(tty) &&
- I_IXANY(tty)) {
- start_tty(tty);
- process_echoes(tty);
- }
-
- parmrk = (c == (unsigned char) '\377' && I_PARMRK(tty)) ? 1 : 0;
- if (read_cnt(ldata) >= (N_TTY_BUF_SIZE - parmrk - 1)) {
- /* beep if no space */
- if (L_ECHO(tty))
- process_output('\a', tty);
- return;
- }
- if (L_ECHO(tty)) {
- finish_erasing(ldata);
- /* Record the column of first canon char. */
- if (ldata->canon_head == ldata->read_head)
- echo_set_canon_col(ldata);
- echo_char(c, tty);
- commit_echoes(tty);
- }
- if (parmrk)
- put_tty_queue(c, ldata);
- put_tty_queue(c, ldata);
- return;
- }
-
if (I_IXON(tty)) {
if (c == START_CHAR(tty)) {
start_tty(tty);
@@ -1456,6 +1411,60 @@ handle_newline:
put_tty_queue(c, ldata);
}
+static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
+{
+ struct n_tty_data *ldata = tty->disc_data;
+ int parmrk;
+
+ if (I_ISTRIP(tty))
+ c &= 0x7f;
+ if (I_IUCLC(tty) && L_IEXTEN(tty))
+ c = tolower(c);
+
+ if (L_EXTPROC(tty)) {
+ put_tty_queue(c, ldata);
+ return;
+ }
+
+ /*
+* If the previous character was LNEXT, or we know that this
+* character is not one of the characters that we'll have to
+* handle specially, do shortcut processing to speed things
+* up.
+*/
+ if (!test_bit(c, ldata->char_map) || ldata->lnext) {
+ ldata->lnext = 0;
+
+ if (tty->stopped && !tty->flow_stopped && I_IXON(tty) &&
+ I_IXANY(tty)) {
+ start_tty(tty);
+ process_echoes(tty);
+ }
+
+ parmrk = (c == (unsigned char) '\377' && I_PARMRK(tty)) ? 1 : 0;
+ if (read_cnt(ldata) >= (N_TTY_BUF_SIZE - parmrk - 1)) {
+ /* beep if no space */
+ if (L_ECHO(tty))
+ process_output('\a', tty);
+ return;
+ }
+ if (L_ECHO(tty)) {
+ finish_erasing(ldata);
+ /* Record the column of first canon char. */
+ if (ldata->canon_head == ldata->read_head)
+ echo_set_canon_col(ldata);
+ echo_char(c, tty);
+ commit_echoes(tty);
+ }
+ if (parmrk)
+ put_tty_queue(c, ldata);
+ put_tty_queue(c, ldata);
+ return;
+ }
+
+ n_tty_receive_char_special(tty, c);
+}
+
static inline void
n_tty_receive_char_closing(struct tty_struct *tty, unsigned char c)
{
--
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/
