Re: [PATCH v2 10/11] HID: introduce Scan Time
On Wed, Oct 31, 2012 at 8:16 PM, Henrik Rydberg rydb...@euromail.se wrote: Hi Benjamin, This is a nice feature, useful in many other contexts. As such, I think it should be defined in the context of the input subsystem, with a more specific definition added to the documentation. For instance, is 100us suitable? When should it start at zero, at BTN_TOUCH? Or should it perhaps wrap around on unsigned integer instead? Or display the difference from the last event? Well, the thing is that I didn't wanted to copy/paste win 8 definition for ScanTime. So I put it with my words and not in a very understandable way :) This allows me to forward the incoming events without having to do anything on them... - 100us: suitable, not sure, but it would be good to define a standard unit for time too Units of 100us might be fine, but maybe 64 or 128 or even 1 might be better suited for implementations. - start at zero at BTN_TOUCH: no. This information allows us to do much better false release detection. If we reset this counter, then we will loose the time between the two touch/release. Good point. The spec says that it is up to the device to reset it after a period of time (not defined, but can be one second for instance). Last, BTN_TOUCH is not reliable for hovering devices because we will still get finger information without BTN_TOUCH. Agreed. - difference from the last event: not sure how it is implemented in windows, but I'm not sure it's a good way of doing if the gesture engine needs the time from the beginning of the touch... Probably more complicated than it needs to be, yes. Anyway, I would be happy to have other comments/proposals for this event code. Here is my proposal: Let ABS_SCAN_TIME be the number of microseconds since the last reset. Let it be coded as an uint32 value, which is allowed to wrap around with no special consequence. It is assumed that the time difference between two consecutive events is reliable on a reasonable time scale (hours). A reset to zero can happen, in which case the time since the last event is unknown. A definition like time_valid = (time || (time - prev_time) MAX_SCAN_INTERVAL) ought to work for most cases. all right, I'm fine with it. diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index 53305bd..8f8c908 100644 --- a/Documentation/input/event-codes.txt +++ b/Documentation/input/event-codes.txt @@ -174,6 +174,13 @@ A few EV_ABS codes have special meanings: the input device may be used freely in three dimensions, consider ABS_Z instead. +* ABS_SCAN_TIME: + - Used when the device provides a timestamp for each frame. The unit must be +100us, and may be reset when the device don't send any events for a +period of time. The values increment at each frame and thus, it can roll +back to 0 when reach logical_max. If the device does not provide this +information, the driver must not provide it to the user space. + * ABS_MT_name: - Used to describe multitouch input events. Please see multi-touch-protocol.txt for details. diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index 16cc89a..5fe7bd3 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -675,6 +675,10 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel map_key_clear(BTN_STYLUS2); break; + case 0x56: /* Scan Time */ + map_abs(ABS_SCAN_TIME); + break; + Is it not enough to map it in the case below? Or you mean this is picked up by hid core? in hidinput_configure_usage, it's enough to just map it. In hid-multitouch, We also just need to map it, and it will be handled by hid-core in the .event callback. I think you should intercept it, convert it, and send it out with the touch frame. With the definition inspired from Win 8, I didn't need to convert it, thus the hid-core could handle it. Now, it's clear that if we want to transform it, it needs to be intercepted. Cheers, Benjamin Thanks, Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [trivial] sound: soc: Fix typo in sound/codecs
Correct spelling typo in sound/soc/codecs
Signed-off-by: Masanari Iida standby2...@gmail.com
---
sound/soc/codecs/ab8500-codec.c | 2 +-
sound/soc/codecs/wm8974.c | 6 +++---
sound/soc/codecs/wm8978.c | 6 +++---
sound/soc/codecs/wm8983.c | 6 +++---
sound/soc/codecs/wm8985.c | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c
index af54749..f848878 100644
--- a/sound/soc/codecs/ab8500-codec.c
+++ b/sound/soc/codecs/ab8500-codec.c
@@ -2147,7 +2147,7 @@ static int ab8500_codec_set_dai_fmt(struct snd_soc_dai
*dai, unsigned int fmt)
status = ab8500_codec_set_dai_clock_gate(codec, fmt);
if (status) {
dev_err(dai-codec-dev,
- %s: ERRROR: Failed to set clock gate (%d).\n,
+ %s: ERROR: Failed to set clock gate (%d).\n,
__func__, status);
return status;
}
diff --git a/sound/soc/codecs/wm8974.c b/sound/soc/codecs/wm8974.c
index 9a39511..cc4c1c0 100644
--- a/sound/soc/codecs/wm8974.c
+++ b/sound/soc/codecs/wm8974.c
@@ -113,15 +113,15 @@ SOC_ENUM(Equaliser Function, wm8974_enum[3]),
SOC_ENUM(EQ1 Cut Off, wm8974_enum[4]),
SOC_SINGLE_TLV(EQ1 Volume, WM8974_EQ1, 0, 24, 1, eq_tlv),
-SOC_ENUM(Equaliser EQ2 Bandwith, wm8974_enum[5]),
+SOC_ENUM(Equaliser EQ2 Bandwidth, wm8974_enum[5]),
SOC_ENUM(EQ2 Cut Off, wm8974_enum[6]),
SOC_SINGLE_TLV(EQ2 Volume, WM8974_EQ2, 0, 24, 1, eq_tlv),
-SOC_ENUM(Equaliser EQ3 Bandwith, wm8974_enum[7]),
+SOC_ENUM(Equaliser EQ3 Bandwidth, wm8974_enum[7]),
SOC_ENUM(EQ3 Cut Off, wm8974_enum[8]),
SOC_SINGLE_TLV(EQ3 Volume, WM8974_EQ3, 0, 24, 1, eq_tlv),
-SOC_ENUM(Equaliser EQ4 Bandwith, wm8974_enum[9]),
+SOC_ENUM(Equaliser EQ4 Bandwidth, wm8974_enum[9]),
SOC_ENUM(EQ4 Cut Off, wm8974_enum[10]),
SOC_SINGLE_TLV(EQ4 Volume, WM8974_EQ4, 0, 24, 1, eq_tlv),
diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c
index 5421fd9..4302071 100644
--- a/sound/soc/codecs/wm8978.c
+++ b/sound/soc/codecs/wm8978.c
@@ -166,15 +166,15 @@ static const struct snd_kcontrol_new
wm8978_snd_controls[] = {
SOC_ENUM(EQ1 Cut Off, eq1),
SOC_SINGLE_TLV(EQ1 Volume, WM8978_EQ1, 0, 24, 1, eq_tlv),
- SOC_ENUM(Equaliser EQ2 Bandwith, eq2bw),
+ SOC_ENUM(Equaliser EQ2 Bandwidth, eq2bw),
SOC_ENUM(EQ2 Cut Off, eq2),
SOC_SINGLE_TLV(EQ2 Volume, WM8978_EQ2, 0, 24, 1, eq_tlv),
- SOC_ENUM(Equaliser EQ3 Bandwith, eq3bw),
+ SOC_ENUM(Equaliser EQ3 Bandwidth, eq3bw),
SOC_ENUM(EQ3 Cut Off, eq3),
SOC_SINGLE_TLV(EQ3 Volume, WM8978_EQ3, 0, 24, 1, eq_tlv),
- SOC_ENUM(Equaliser EQ4 Bandwith, eq4bw),
+ SOC_ENUM(Equaliser EQ4 Bandwidth, eq4bw),
SOC_ENUM(EQ4 Cut Off, eq4),
SOC_SINGLE_TLV(EQ4 Volume, WM8978_EQ4, 0, 24, 1, eq_tlv),
diff --git a/sound/soc/codecs/wm8983.c b/sound/soc/codecs/wm8983.c
index d8879f2..494e42f 100644
--- a/sound/soc/codecs/wm8983.c
+++ b/sound/soc/codecs/wm8983.c
@@ -353,13 +353,13 @@ static const struct snd_kcontrol_new
wm8983_snd_controls[] = {
SOC_ENUM_EXT(Equalizer Function, eqmode, eqmode_get, eqmode_put),
SOC_ENUM(EQ1 Cutoff, eq1_cutoff),
SOC_SINGLE_TLV(EQ1 Volume, WM8983_EQ1_LOW_SHELF, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ2 Bandwith, eq2_bw),
+ SOC_ENUM(EQ2 Bandwidth, eq2_bw),
SOC_ENUM(EQ2 Cutoff, eq2_cutoff),
SOC_SINGLE_TLV(EQ2 Volume, WM8983_EQ2_PEAK_1, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ3 Bandwith, eq3_bw),
+ SOC_ENUM(EQ3 Bandwidth, eq3_bw),
SOC_ENUM(EQ3 Cutoff, eq3_cutoff),
SOC_SINGLE_TLV(EQ3 Volume, WM8983_EQ3_PEAK_2, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ4 Bandwith, eq4_bw),
+ SOC_ENUM(EQ4 Bandwidth, eq4_bw),
SOC_ENUM(EQ4 Cutoff, eq4_cutoff),
SOC_SINGLE_TLV(EQ4 Volume, WM8983_EQ4_PEAK_3, 0, 24, 1, eq_tlv),
SOC_ENUM(EQ5 Cutoff, eq5_cutoff),
diff --git a/sound/soc/codecs/wm8985.c b/sound/soc/codecs/wm8985.c
index 14f6663..3b37fc4 100644
--- a/sound/soc/codecs/wm8985.c
+++ b/sound/soc/codecs/wm8985.c
@@ -371,13 +371,13 @@ static const struct snd_kcontrol_new
wm8985_snd_controls[] = {
SOC_ENUM_EXT(Equalizer Function, eqmode, eqmode_get, eqmode_put),
SOC_ENUM(EQ1 Cutoff, eq1_cutoff),
SOC_SINGLE_TLV(EQ1 Volume, WM8985_EQ1_LOW_SHELF, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ2 Bandwith, eq2_bw),
+ SOC_ENUM(EQ2 Bandwidth, eq2_bw),
SOC_ENUM(EQ2 Cutoff, eq2_cutoff),
SOC_SINGLE_TLV(EQ2 Volume, WM8985_EQ2_PEAK_1, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ3 Bandwith, eq3_bw),
+ SOC_ENUM(EQ3 Bandwidth, eq3_bw),
SOC_ENUM(EQ3 Cutoff, eq3_cutoff),
SOC_SINGLE_TLV(EQ3 Volume, WM8985_EQ3_PEAK_2, 0, 24, 1, eq_tlv),
- SOC_ENUM(EQ4 Bandwith, eq4_bw),
+ SOC_ENUM(EQ4 Bandwidth, eq4_bw),
SOC_ENUM(EQ4 Cutoff, eq4_cutoff),
SOC_SINGLE_TLV(EQ4 Volume, WM8985_EQ4_PEAK_3, 0, 24,
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Balbir Singh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/2] xen-pciback: parsing improvements
1: simplify and tighten parsing of device IDs 2: reject out of range inputs Signed-off-by: Jan Beulich jbeul...@suse.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] xen-pciback: simplify and tighten parsing of device IDs
Now that at least one of the conformance problems of the kernel's
sscanf() was addressed (commit da99075c1d368315e1508b6143226c0d27b621e0),
we can improve the parsing done in xen-pciback both in terms of code
readability and correctness (in particular properly rejecting input
strings not well formed).
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/xen-pciback/pci_stub.c | 83 +
1 file changed, 39 insertions(+), 44 deletions(-)
--- 3.7-rc3-xen-pciback.orig/drivers/xen/xen-pciback/pci_stub.c
+++ 3.7-rc3-xen-pciback/drivers/xen/xen-pciback/pci_stub.c
@@ -897,42 +897,35 @@ static struct pci_driver xen_pcibk_pci_d
static inline int str_to_slot(const char *buf, int *domain, int *bus,
int *slot, int *func)
{
- int err;
- char wc = '*';
+ int parsed = 0;
- err = sscanf(buf, %x:%x:%x.%x, domain, bus, slot, func);
- switch (err) {
+ switch (sscanf(buf, %x:%x:%x.%x %n, domain, bus, slot, func,
+ parsed)) {
case 3:
*func = -1;
- err = sscanf(buf, %x:%x:%x.%c, domain, bus, slot, wc);
+ sscanf(buf, %x:%x:%x.* %n, domain, bus, slot, parsed);
break;
case 2:
*slot = *func = -1;
- err = sscanf(buf, %x:%x:*.%c, domain, bus, wc);
- if (err = 2)
- ++err;
+ sscanf(buf, %x:%x:*.* %n, domain, bus, parsed);
break;
}
- if (err == 4 wc == '*')
+ if (parsed !buf[parsed])
return 0;
- else if (err 0)
- return -EINVAL;
/* try again without domain */
*domain = 0;
- wc = '*';
- err = sscanf(buf, %x:%x.%x, bus, slot, func);
- switch (err) {
+ switch (sscanf(buf, %x:%x.%x %n, bus, slot, func, parsed)) {
case 2:
*func = -1;
- err = sscanf(buf, %x:%x.%c, bus, slot, wc);
+ sscanf(buf, %x:%x.* %n, bus, slot, parsed);
break;
case 1:
*slot = *func = -1;
- err = sscanf(buf, %x:*.%c, bus, wc) + 1;
+ sscanf(buf, %x:*.* %n, bus, parsed);
break;
}
- if (err == 3 wc == '*')
+ if (parsed !buf[parsed])
return 0;
return -EINVAL;
@@ -941,13 +934,20 @@ static inline int str_to_slot(const char
static inline int str_to_quirk(const char *buf, int *domain, int *bus, int
*slot, int *func, int *reg, int *size, int *mask)
{
- int err;
+ int parsed = 0;
+
+ sscanf(buf, %4x:%2x:%2x.%d-%8x:%1x:%8x %n, domain, bus, slot, func,
+ reg, size, mask, parsed);
+ if (parsed !buf[parsed])
+ return 0;
- err =
- sscanf(buf, %04x:%02x:%02x.%d-%08x:%1x:%08x, domain, bus, slot,
- func, reg, size, mask);
- if (err == 7)
+ /* try again without domain */
+ *domain = 0;
+ sscanf(buf, %2x:%2x.%d-%8x:%1x:%8x %n, bus, slot, func, reg, size,
+ mask, parsed);
+ if (parsed !buf[parsed])
return 0;
+
return -EINVAL;
}
@@ -1339,8 +1339,6 @@ static int __init pcistub_init(void)
if (pci_devs_to_hide *pci_devs_to_hide) {
do {
- char wc = '*';
-
parsed = 0;
err = sscanf(pci_devs_to_hide + pos,
@@ -1349,51 +1347,48 @@ static int __init pcistub_init(void)
switch (err) {
case 3:
func = -1;
- err = sscanf(pci_devs_to_hide + pos,
- (%x:%x:%x.%c) %n,
-domain, bus, slot, wc,
-parsed);
+ sscanf(pci_devs_to_hide + pos,
+ (%x:%x:%x.*) %n,
+ domain, bus, slot, parsed);
break;
case 2:
slot = func = -1;
- err = sscanf(pci_devs_to_hide + pos,
- (%x:%x:*.%c) %n,
-domain, bus, wc, parsed) + 1;
+ sscanf(pci_devs_to_hide + pos,
+ (%x:%x:*.*) %n,
+ domain, bus, parsed);
break;
}
- if (err != 4 || wc != '*') {
+ if (!parsed) {
domain = 0;
- wc = '*';
err = sscanf(pci_devs_to_hide + pos,
[PATCH] [trivial] net: bnx2x: Fix typo in bnx2x driver
Correct spelling typo in bnx2x driver
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index c65295d..6e5bdd1 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -1702,7 +1702,7 @@ static int bnx2x_set_eee(struct net_device *dev, struct
ethtool_eee *edata)
SHMEM_EEE_ADV_STATUS_SHIFT);
if ((advertised != (eee_cfg SHMEM_EEE_ADV_STATUS_MASK))) {
DP(BNX2X_MSG_ETHTOOL,
- Direct manipulation of EEE advertisment is not
supported\n);
+ Direct manipulation of EEE advertisement is not
supported\n);
return -EINVAL;
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index e2e45ee..5be223e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -9878,7 +9878,7 @@ static int bnx2x_848x3_config_init(struct bnx2x_phy *phy,
else
rc = bnx2x_8483x_disable_eee(phy, params, vars);
if (rc) {
- DP(NETIF_MSG_LINK, Failed to set EEE advertisment\n);
+ DP(NETIF_MSG_LINK, Failed to set EEE advertisement\n);
return rc;
}
} else {
@@ -12919,7 +12919,7 @@ static u8 bnx2x_analyze_link_error(struct link_params
*params,
DP(NETIF_MSG_LINK, Analyze TX Fault\n);
break;
default:
- DP(NETIF_MSG_LINK, Analyze UNKOWN\n);
+ DP(NETIF_MSG_LINK, Analyze UNKNOWN\n);
}
DP(NETIF_MSG_LINK, Link changed:[%x %x]-%x\n, vars-link_up,
old_status, status);
--
1.8.0.rc3.16.g8ead1bf
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] xen-pciback: reject out of range inputs
This add checks for out of range numbers (including in cases where the
folding of slot and function into a single value could yield false
matches).
It also removes the bogus field width restrictions in str_to_quirk() -
nowhere else in the driver this is being done, and hence this function
could reject input the equivalent of which would be happily accepted
in other places (in particular, 0x prefixes causing the effective
width of the actual number to be either zero or less than what would be
required to cover the full range of valid values). Note that for the
moment this second part is cosmetic only, as the kernel's sscanf()
currently ignores the field widths, but a patch to overcome this is on
its way.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/xen-pciback/pci_stub.c | 39 +
1 file changed, 27 insertions(+), 12 deletions(-)
--- 3.7-rc3-xen-pciback.orig/drivers/xen/xen-pciback/pci_stub.c
+++ 3.7-rc3-xen-pciback/drivers/xen/xen-pciback/pci_stub.c
@@ -142,7 +142,8 @@ static struct pcistub_device *pcistub_de
if (psdev-dev != NULL
domain == pci_domain_nr(psdev-dev-bus)
bus == psdev-dev-bus-number
-PCI_DEVFN(slot, func) == psdev-dev-devfn) {
+slot == PCI_SLOT(psdev-dev-devfn)
+func == PCI_FUNC(psdev-dev-devfn)) {
pcistub_device_get(psdev);
goto out;
}
@@ -191,7 +192,8 @@ struct pci_dev *pcistub_get_pci_dev_by_s
if (psdev-dev != NULL
domain == pci_domain_nr(psdev-dev-bus)
bus == psdev-dev-bus-number
-PCI_DEVFN(slot, func) == psdev-dev-devfn) {
+slot == PCI_SLOT(psdev-dev-devfn)
+func == PCI_FUNC(psdev-dev-devfn)) {
found_dev = pcistub_device_get_pci_dev(pdev, psdev);
break;
}
@@ -936,14 +938,14 @@ static inline int str_to_quirk(const cha
{
int parsed = 0;
- sscanf(buf, %4x:%2x:%2x.%d-%8x:%1x:%8x %n, domain, bus, slot, func,
+ sscanf(buf, %x:%x:%x.%x-%x:%x:%x %n, domain, bus, slot, func,
reg, size, mask, parsed);
if (parsed !buf[parsed])
return 0;
/* try again without domain */
*domain = 0;
- sscanf(buf, %2x:%2x.%d-%8x:%1x:%8x %n, bus, slot, func, reg, size,
+ sscanf(buf, %x:%x.%x-%x:%x:%x %n, bus, slot, func, reg, size,
mask, parsed);
if (parsed !buf[parsed])
return 0;
@@ -955,7 +957,7 @@ static int pcistub_device_id_add(int dom
{
struct pcistub_device_id *pci_dev_id;
unsigned long flags;
- int rc = 0;
+ int rc = 0, devfn = PCI_DEVFN(slot, func);
if (slot 0) {
for (slot = 0; !rc slot 32; ++slot)
@@ -969,13 +971,24 @@ static int pcistub_device_id_add(int dom
return rc;
}
+ if ((
+#if !defined(MODULE) /* pci_domains_supported is not being exported */ \
+|| !defined(CONFIG_PCI_DOMAINS)
+!pci_domains_supported ? domain :
+#endif
+domain 0 || domain 0x)
+ || bus 0 || bus 0xff
+ || PCI_SLOT(devfn) != slot
+ || PCI_FUNC(devfn) != func)
+ return -EINVAL;
+
pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
if (!pci_dev_id)
return -ENOMEM;
pci_dev_id-domain = domain;
pci_dev_id-bus = bus;
- pci_dev_id-devfn = PCI_DEVFN(slot, func);
+ pci_dev_id-devfn = devfn;
pr_debug(DRV_NAME : wants to seize %04x:%02x:%02x.%d\n,
domain, bus, slot, func);
@@ -1016,14 +1029,18 @@ static int pcistub_device_id_remove(int
return err;
}
-static int pcistub_reg_add(int domain, int bus, int slot, int func, int reg,
- int size, int mask)
+static int pcistub_reg_add(int domain, int bus, int slot, int func,
+ unsigned int reg, unsigned int size,
+ unsigned int mask)
{
int err = 0;
struct pcistub_device *psdev;
struct pci_dev *dev;
struct config_field *field;
+ if (reg 0xfff || (size 4 (mask (size * 8
+ return -EINVAL;
+
psdev = pcistub_device_find(domain, bus, slot, func);
if (!psdev) {
err = -ENODEV;
@@ -1254,13 +1271,11 @@ static ssize_t permissive_add(struct dev
int err;
struct pcistub_device *psdev;
struct xen_pcibk_dev_data *dev_data;
+
err = str_to_slot(buf, domain, bus, slot, func);
if (err)
goto out;
- if (slot 0 || func 0) {
- err = -EINVAL;
- goto out;
- }
+
psdev = pcistub_device_find(domain, bus, slot, func);
if (!psdev) {
Re: Kdump with signed images
On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote: On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Yes I have seen this. IIUC, it says that build libc with -enable-static-nss and then individual programs need to statically build against the nss modules program will use. I think building libc with -enable-static-nss part will be unacceptable for general server as other programs would like to make use of the existing nss functionality. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/32] [RFC] nohz/cpuset: Start discussions on nohz CPUs
On Fri, 2012-11-02 at 14:23 +, Christoph Lameter wrote: On Mon, 29 Oct 2012, Steven Rostedt wrote: A while ago Frederic posted a series of patches to get an idea on how to implement nohz cpusets. Where you can add a task to a cpuset and mark the set to be 'nohz'. When the task runs on a CPU and is the only task scheduled (nr_running == 1), the tick will stop. The idea is to give the task the least amount of kernel interference as possible. If the task doesn't do any system calls (and possibly even if it does), no timer interrupt will bother it. By using isocpus and nohz cpuset, a task would be able to achieve true cpu isolation. I thought isolcpus was on the way out? If there is no timer interrupt then there will also be no scheduler activity. Why do we need both? I probably shouldn't have mentioned isolcpus. I was using that as something that is general to get everything off of a cpu (irq affinity for example). Also could we have this support without cpusets? There are multiple means to do system segmentation (f.e. cgroups) and something like hz control is pretty basic. Control via some cpumask like irq affinities in f.e. /sys/devices/system/cpu/nohz or a per cpu flag in /sys/devices/system/cpu/cpu0/hz would be easier and not be tied to something like cpusets. Frederic will have to answer this. I was just starting with his patches. Note, we are holding off this work for now until Frederic's other work is done (the irq_work and printk updates). also it would be best to sync this conceptually with the processors enabled for rcu processing. Processors can be disabled for rcu processing? Or are you talking about Paul's new work of offloading rcu callbacks? Maybe have a series of cpumasks in /sys/devices/system/cpu/ ? This has been long asked for by those in the RT community. If a task requires uninterruptible CPU time, this would be able to give a task that, even without the full PREEMPT-RT patch set. Also those interested in low latency are very very interested in this feature in particular in support without any preempt support on in the kernel. Yep understood. We really need to get things rolling. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL v2] IBM vTPM driver update
On Thu, 1 Nov 2012, Kent Yoder wrote:
Hi James,
This time against security-next...
Thanks, pulled.
The following changes since commit 61d335dd27c67d656f114c091a46cf95cbeeb77c:
Merge branch 'security-next-keys' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/security-keys into
next-queue (2012-10-03 13:00:17 +1000)
are available in the git repository at:
git://github.com/shpedoikal/linux.git tpmdd-11-1-12
for you to fetch changes up to b5666502700855a1eb1a15482005b22478b9460e:
drivers/char/tpm: remove tasklet and cleanup (2012-11-01 15:23:14 -0500)
Ashley Lai (1):
drivers/char/tpm: remove tasklet and cleanup
drivers/char/tpm/tpm_ibmvtpm.c | 81
+++---
drivers/char/tpm/tpm_ibmvtpm.h | 5 ++-
2 files changed, 30 insertions(+), 56 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index efc4ab3..88a95ea 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -38,8 +38,6 @@ static struct vio_device_id tpm_ibmvtpm_device_table[]
__devinitdata = {
};
MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
-DECLARE_WAIT_QUEUE_HEAD(wq);
-
/**
* ibmvtpm_send_crq - Send a CRQ request
* @vdev:vio device struct
@@ -83,6 +81,7 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf,
size_t count)
{
struct ibmvtpm_dev *ibmvtpm;
u16 len;
+ int sig;
ibmvtpm = (struct ibmvtpm_dev *)chip-vendor.data;
@@ -91,22 +90,23 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8
*buf, size_t count)
return 0;
}
- wait_event_interruptible(wq, ibmvtpm-crq_res.len != 0);
+ sig = wait_event_interruptible(ibmvtpm-wq, ibmvtpm-res_len != 0);
+ if (sig)
+ return -EINTR;
+
+ len = ibmvtpm-res_len;
- if (count ibmvtpm-crq_res.len) {
+ if (count len) {
dev_err(ibmvtpm-dev,
Invalid size in recv: count=%ld, crq_size=%d\n,
- count, ibmvtpm-crq_res.len);
+ count, len);
return -EIO;
}
spin_lock(ibmvtpm-rtce_lock);
- memcpy((void *)buf, (void *)ibmvtpm-rtce_buf, ibmvtpm-crq_res.len);
- memset(ibmvtpm-rtce_buf, 0, ibmvtpm-crq_res.len);
- ibmvtpm-crq_res.valid = 0;
- ibmvtpm-crq_res.msg = 0;
- len = ibmvtpm-crq_res.len;
- ibmvtpm-crq_res.len = 0;
+ memcpy((void *)buf, (void *)ibmvtpm-rtce_buf, len);
+ memset(ibmvtpm-rtce_buf, 0, len);
+ ibmvtpm-res_len = 0;
spin_unlock(ibmvtpm-rtce_lock);
return len;
}
@@ -273,7 +273,6 @@ static int __devexit tpm_ibmvtpm_remove(struct vio_dev
*vdev)
int rc = 0;
free_irq(vdev-irq, ibmvtpm);
- tasklet_kill(ibmvtpm-tasklet);
do {
if (rc)
@@ -372,7 +371,6 @@ static int ibmvtpm_reset_crq(struct ibmvtpm_dev *ibmvtpm)
static int tpm_ibmvtpm_resume(struct device *dev)
{
struct ibmvtpm_dev *ibmvtpm = ibmvtpm_get_data(dev);
- unsigned long flags;
int rc = 0;
do {
@@ -387,10 +385,11 @@ static int tpm_ibmvtpm_resume(struct device *dev)
return rc;
}
- spin_lock_irqsave(ibmvtpm-lock, flags);
- vio_disable_interrupts(ibmvtpm-vdev);
- tasklet_schedule(ibmvtpm-tasklet);
- spin_unlock_irqrestore(ibmvtpm-lock, flags);
+ rc = vio_enable_interrupts(ibmvtpm-vdev);
+ if (rc) {
+ dev_err(dev, Error vio_enable_interrupts rc=%d\n, rc);
+ return rc;
+ }
rc = ibmvtpm_crq_send_init(ibmvtpm);
if (rc)
@@ -467,7 +466,7 @@ static struct ibmvtpm_crq *ibmvtpm_crq_get_next(struct
ibmvtpm_dev *ibmvtpm)
if (crq-valid VTPM_MSG_RES) {
if (++crq_q-index == crq_q-num_entry)
crq_q-index = 0;
- rmb();
+ smp_rmb();
} else
crq = NULL;
return crq;
@@ -535,11 +534,9 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
ibmvtpm-vtpm_version = crq-data;
return;
case VTPM_TPM_COMMAND_RES:
- ibmvtpm-crq_res.valid = crq-valid;
- ibmvtpm-crq_res.msg = crq-msg;
- ibmvtpm-crq_res.len = crq-len;
- ibmvtpm-crq_res.data = crq-data;
- wake_up_interruptible(wq);
+ /* len of the data in rtce buffer */
+ ibmvtpm-res_len = crq-len;
+ wake_up_interruptible(ibmvtpm-wq);
return;
default:
return;
@@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
{
struct
[PATCH] sscanf: don't ignore field widths for numeric conversions
This is another step towards better standard conformance. Rather than
adding a local buffer to store the specified portion of the string
(with the need to enforce an arbitrary maximum supported width to
limit the buffer size), do a maximum width conversion and then drop as
much of it as is necessary to meet the caller's request.
Also fail on negative field widths.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
lib/vsprintf.c | 96 +++--
1 file changed, 53 insertions(+), 43 deletions(-)
--- 3.7-rc3/lib/vsprintf.c
+++ 3.7-rc3-sscanf-field-width/lib/vsprintf.c
@@ -23,12 +23,12 @@
#include linux/ctype.h
#include linux/kernel.h
#include linux/kallsyms.h
+#include linux/math64.h
#include linux/uaccess.h
#include linux/ioport.h
#include net/addrconf.h
#include asm/page.h /* for PAGE_SIZE */
-#include asm/div64.h
#include asm/sections.h /* for dereference_function_descriptor() */
#include kstrtox.h
@@ -2013,7 +2013,11 @@ int vsscanf(const char *buf, const char
char digit;
int num = 0;
u8 qualifier;
- u8 base;
+ unsigned int base;
+ union {
+ long long s;
+ unsigned long long u;
+ } val;
s16 field_width;
bool is_sign;
@@ -2053,8 +2057,11 @@ int vsscanf(const char *buf, const char
/* get field width */
field_width = -1;
- if (isdigit(*fmt))
+ if (isdigit(*fmt)) {
field_width = skip_atoi(fmt);
+ if (field_width = 0)
+ break;
+ }
/* get conversion qualifier */
qualifier = -1;
@@ -2154,58 +2161,61 @@ int vsscanf(const char *buf, const char
|| (base == 0 !isdigit(digit)))
break;
+ if (is_sign)
+ val.s = qualifier != 'L' ?
+ simple_strtol(str, next, base) :
+ simple_strtoll(str, next, base);
+ else
+ val.u = qualifier != 'L' ?
+ simple_strtoul(str, next, base) :
+ simple_strtoull(str, next, base);
+
+ if (field_width 0 next - str field_width) {
+ if (base == 0)
+ _parse_integer_fixup_radix(str, base);
+ while (next - str field_width) {
+ if (is_sign)
+ val.s = div_s64(val.s, base);
+ else
+ val.u = div_u64(val.u, base);
+ --next;
+ }
+ }
+
switch (qualifier) {
case 'H': /* that's 'hh' in format */
- if (is_sign) {
- signed char *s = (signed char *)va_arg(args,
signed char *);
- *s = (signed char)simple_strtol(str, next,
base);
- } else {
- unsigned char *s = (unsigned char
*)va_arg(args, unsigned char *);
- *s = (unsigned char)simple_strtoul(str, next,
base);
- }
+ if (is_sign)
+ *va_arg(args, signed char *) = val.s;
+ else
+ *va_arg(args, unsigned char *) = val.u;
break;
case 'h':
- if (is_sign) {
- short *s = (short *)va_arg(args, short *);
- *s = (short)simple_strtol(str, next, base);
- } else {
- unsigned short *s = (unsigned short
*)va_arg(args, unsigned short *);
- *s = (unsigned short)simple_strtoul(str, next,
base);
- }
+ if (is_sign)
+ *va_arg(args, short *) = val.s;
+ else
+ *va_arg(args, unsigned short *) = val.u;
break;
case 'l':
- if (is_sign) {
- long *l = (long *)va_arg(args, long *);
- *l = simple_strtol(str, next, base);
- } else {
- unsigned long *l = (unsigned long
*)va_arg(args, unsigned long *);
- *l = simple_strtoul(str, next, base);
- }
+ if (is_sign)
+ *va_arg(args, long *) = val.s;
+ else
+ *va_arg(args, unsigned long *) = val.u;
[PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it
This makes the resulting diagnostics quite a bit more useful.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
include/linux/bug.h | 16
1 file changed, 16 insertions(+)
--- 3.7-rc3/include/linux/bug.h
+++ 3.7-rc3-static-assert/include/linux/bug.h
@@ -27,8 +27,15 @@ struct pt_regs;
result (of value 0 and type size_t), so the expression can be used
e.g. in a structure initializer (or where-ever else comma expressions
aren't permitted). */
+#if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ = 6)
+#define BUILD_BUG_ON_ZERO(e) \
+ sizeof(struct { _Static_assert(!(e), !( #e )); })
+#define BUILD_BUG_ON_NULL(e) \
+ ((void *)sizeof(struct { _Static_assert(!(e), !( #e )); }))
+#else
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+#endif
/*
* BUILD_BUG_ON_INVALID() permits the compiler to check the validity of the
@@ -54,6 +61,15 @@ struct pt_regs;
*/
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#elif __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ = 3)
+#define __build_bug_on_failed(n) __build_bug_on_##n##_failed
+#define _BUILD_BUG_ON(n, condition)\
+ do {\
+ extern void __compiletime_error(#condition) \
+ __build_bug_on_failed(n)(void); \
+ if (condition) __build_bug_on_failed(n)(); \
+ } while(0)
+#define BUILD_BUG_ON(condition...) _BUILD_BUG_ON(__COUNTER__, ##condition)
#else
extern int __build_bug_on_failed;
#define BUILD_BUG_ON(condition)\
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
Il 31/10/2012 22:22, Tejun Heo ha scritto: Hello, Paolo. On Thu, Oct 25, 2012 at 02:35:20PM -0400, Paolo Bonzini wrote: Disabling filters if opened by root and tranfering via SCM_RIGHTS would be the simplest interface-wise (there's no new interface at all). Would that be too dangerous security-wise? That would be a change with respect to what we have now. After transferring a root-opened (better: CAP_SYS_RAWIO-opened) file descriptor to an unprivileged process your SG_IO commands get filtered. So a ioctl is needed if you want to rely on SCM_RIGHTS. Yeah, I get that it's a behavior change, but would that be a problem? Worse, it's a potential security hole because previously you'd get filtering and now you wouldn't. Considering that SCM_RIGHTS is usually used to transfer a file descriptor from a privileged process to an unprivileged one, I'd be very worried of that. I guess I just feel quite reluctant to expose another rather obscure userland configurable in-kernel filter and at the same time I'm not sure whether this is flexible enough. What if a device is shared by multiple virtual machines which are trusted at different levels? No, you just don't do that. If a device is passed through to virtual machines, it is between similar virtual machines (for some definition of similar). The only case where you have this sharing is in practice if either the device is read-only (my patch does give you a basic two-level filtering, with two separate bitmaps for RO and RW) or if you allow persistent reservations (which is as close to full trust as you can get). What disturbs me is that it's a completely new interface to userland and at the same a very limited one at that. So, yeah, it's bothersome. I personally would prefer SCM_RIGHTS behavior change + hard coded filters per device class. I think hard-coded filters are bad (I prefer to move policy to userspace), and SCM_RIGHTS without a ioctl is out of question, really. But, I'd really like to hear what other guys are thinking. Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? :P :P Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/32] [RFC] nohz/cpuset: Start discussions on nohz CPUs
On 11/02/2012 03:37 PM, Steven Rostedt wrote:
On Fri, 2012-11-02 at 14:23 +, Christoph Lameter wrote:
On Mon, 29 Oct 2012, Steven Rostedt wrote:
A while ago Frederic posted a series of patches to get an idea on
how to implement nohz cpusets. Where you can add a task to a cpuset
and mark the set to be 'nohz'. When the task runs on a CPU and is
the only task scheduled (nr_running == 1), the tick will stop.
The idea is to give the task the least amount of kernel interference
as possible. If the task doesn't do any system calls (and possibly
even if it does), no timer interrupt will bother it. By using
isocpus and nohz cpuset, a task would be able to achieve true cpu
isolation.
One other aspect that this patch probably needs to address is the cache
localization of irq spinlocks.
At least in 3.6, with !CONFIG_SPARSE_IRQ
--
struct irq_desc irq_desc[NR_IRQS] __cacheline_aligned_in_smp = {
[0 ... NR_IRQS-1] = {
.handle_irq = handle_bad_irq,
.depth = 1,
.lock = __RAW_SPIN_LOCK_UNLOCKED(irq_desc-lock),
}
};
--
You are likely to get a cache miss in the top half of your low latency
CPU anytime some other CPU has taken a spinlock which lies within the
same cache line.
Or is my understanding of the __cacheline_aligned_in_smp declaration wrong ?
Br,
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Thu, Nov 01, 2012 at 10:29:17AM -0400, Eric Paris wrote: On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: But that doesn't really help me: untrusted root is an oxymoron. Imagine you run windows and you've never heard of Linux. You like that only windows kernels can boot on your box and not those mean nasty hacked up malware kernels. Now some attacker manages to take over your box because you clicked on that executable for young models in skimpy bathing suits. That executable rewrote your bootloader to launch a very small carefully crafted Linux environment. This Rewrote bootloader on disk so that it gets executed next time? It will not run as signature will not match. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/2] kbuild: centralize .dts-.dtb rule
On 11/02/2012 04:23 AM, Ralf Baechle wrote:
On Fri, Nov 02, 2012 at 10:58:01AM +0100, Ralf Baechle wrote:
Can you fold these MIPS bits into your patch?
I missed Lantiq.
Thanks, I've squashed that in, and with a quick grep noticed that
arch/{arm64,microblaze} also need updating.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 00/32] [RFC] nohz/cpuset: Start discussions on nohz CPUs
On Fri, 2 Nov 2012, Steven Rostedt wrote: also it would be best to sync this conceptually with the processors enabled for rcu processing. Processors can be disabled for rcu processing? Or are you talking about Paul's new work of offloading rcu callbacks? Yes. Paul's new work to remove rcu processing from processors. That needs to be synced configuration wise somehow. It does not make sense to process rcu callbacks on processors where the timer tick does not work anymore. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ACPI: Introduce a new acpi handle to determine HID match.
On Fri, Nov 2, 2012 at 5:23 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, October 18, 2012 01:50:09 PM Yinghai Lu wrote:
From: Tang Chen tangc...@cn.fujitsu.com
We need to find out if one handle is for root bridge, and install notify
handler for it to handle pci root bus hot add.
At that time, root bridge acpi device is not created yet.
So acpi_match_device_ids() will not work.
This patch add a function to check if new acpi handle's HID matches a list
of IDs. The new api use acpi_device_info instead acpi_device.
-v2: updated changelog, also check length for string info...
change checking sequence by moving string comaring close to for loop.
- Yinghai
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Len Brown l...@kernel.org
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/scan.c | 33 +
include/acpi/acpi_bus.h |2 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5dfec09..33ca993 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -312,6 +312,39 @@ int acpi_match_device_ids(struct acpi_device *device,
}
EXPORT_SYMBOL(acpi_match_device_ids);
+int acpi_match_object_info_ids(struct acpi_device_info *info,
+const struct acpi_device_id *ids)
+{
+ const struct acpi_device_id *id;
+ char *str;
+ u32 len;
+ int i;
+
+ len = info-hardware_id.length;
+ if (len) {
+ str = info-hardware_id.string;
+ if (str)
+ for (id = ids; id-id[0]; id++)
+ if (!strcmp((char *)id-id, str))
+ return 0;
+ }
+
+ for (i = 0; i info-compatible_id_list.count; i++) {
+ len = info-compatible_id_list.ids[i].length;
+ if (!len)
+ continue;
+ str = info-compatible_id_list.ids[i].string;
+ if (!str)
+ continue;
+ for (id = ids; id-id[0]; id++)
+ if (!strcmp((char *)id-id, str))
+ return 0;
+ }
+
+ return -ENOENT;
+}
+EXPORT_SYMBOL(acpi_match_object_info_ids);
EXPORT_SYMBOL_GPL, please?
yes, will change that while sending next version..
+
static void acpi_free_ids(struct acpi_device *device)
{
struct acpi_hardware_id *id, *tmp;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 608f92f..6ac415c 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -374,6 +374,8 @@ int acpi_bus_start(struct acpi_device *device);
acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
int acpi_match_device_ids(struct acpi_device *device,
const struct acpi_device_id *ids);
+int acpi_match_object_info_ids(struct acpi_device_info *info,
+const struct acpi_device_id *ids);
int acpi_create_dir(struct acpi_device *);
void acpi_remove_dir(struct acpi_device *);
I wonder which code path(s) is(are) going to use the new routine?
that is for installing handler for pci root bus removal. will resend
them in batch 3.
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-split-pci-root-hp-2
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=b3752f4571a3db1bbbaf204a6cb85aadbd40b19d
PCI, acpiphp: Separate out hot-add support of pci host bridge
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=bda84c28ae8e00315fcc7dffceb301e082369c3e
PCI: correctly detect ACPI PCI host bridge objects
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] gpio-pch: Set parent dev for gpio chip
This will show the gpio chip as a child node under /sys/bus/pci/devices/:xx:xx.x/ Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com --- drivers/gpio/gpio-pch.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 4ad0c4f..e3a14fe 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -215,6 +215,7 @@ static void pch_gpio_setup(struct pch_gpio *chip) struct gpio_chip *gpio = chip-gpio; gpio-label = dev_name(chip-dev); + gpio-dev = chip-dev; gpio-owner = THIS_MODULE; gpio-direction_input = pch_gpio_direction_input; gpio-get = pch_gpio_get; -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).
[RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM,
because other type come from BIOS or firmware is used by other code(for
example: PCI_MMCONFIG).] On 01/11/2012 (Thu 08:49) Zhang, Jun wrote:
Hello, Anvin
Thank for your advice.
Hello, All
the next patch is made by 2), please review it. Thanks!
Subject: [PATCH] When we are doing a crash dump, we still need non-E820_RAM
memory information in order to do I/O. So only remove all
RAM ranges which need to be dumped.
It is typical to do a short log in the subject, and then a long log
in what would be the following paragraph, i.e.
-
Subject: crash dump: don't delete non-E820_RAM during init
Currently we delete the non-E820_RAM, which causes describe the end
user symptoms here -- i.e. how things visibly break
This happens because describe the underlying technical reason
that causes the problem
We can fix this by doing describe the non-obvious aspects of your
change and why it is the right way to fix the problem
-
This rule of three is a good way to write commit logs. Just remember
(1)symptoms, (2)underlying problem, (3)how best to fix it.
Also, ...
Signed-off-by: jzha144 jun.zh...@intel.com
---
arch/x86/kernel/e820.c |8
arch/x86/kernel/setup.c | 22 ++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index df06ade..0bc1687 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -844,14 +844,6 @@ static int __init parse_memmap_opt(char *p)
return -EINVAL;
if (!strncmp(p, exactmap, 8)) {
-#ifdef CONFIG_CRASH_DUMP
- /*
- * If we are doing a crash dump, we still need to know
- * the real mem size before original memory map is
- * reset.
- */
- saved_max_pfn = e820_end_of_ram_pfn();
-#endif
e820.nr_map = 0;
userdef = 1;
return 0;
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ca45696..5eb178b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -480,6 +480,25 @@ static void __init e820_reserve_setup_data(void)
e820_print_map(reserve setup_data);
}
+#ifdef CONFIG_CRASH_DUMP
+static void __init e820_crashdump_remove_ram(void)
+{
... if you move this ifdef/endif within the { } of the function, then
we'll have one less ugly ifdef set below at the call site.
I'll leave the real technical review for Peter, who understands this
area better than I ever will.
Thanks,
Paul.
--
+ /*
+ * We are doing a crash dump, so remove all RAM ranges
+ * as they are the ones that need to be dumped.
+ * We still need all non-RAM information in order to do I/O.
+ */
+ /* NOTE: if you use old kexec, please remove memmap=exactmap
+ * which remove all ranges, not only RAM ranges.
+ */
+ saved_max_pfn = e820_end_of_ram_pfn();
+ e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);
+ sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), e820.nr_map);
+ printk(KERN_INFO crash dump non-RAM map:\n);
+ e820_print_map(crash_dump);
+}
+#endif
+
static void __init memblock_x86_reserve_range_setup_data(void)
{
struct setup_data *data;
@@ -751,6 +770,9 @@ void __init setup_arch(char **cmdline_p)
parse_setup_data();
/* update the e820_saved too */
e820_reserve_setup_data();
+#ifdef CONFIG_CRASH_DUMP
+ e820_crashdump_remove_ram();
+#endif
copy_edd();
--
1.7.6
Best Regards!
Jun Zhang
Inet: 8821-4273
Dir.Tel: 86-21-6116-4273
Email: jun.zh...@intel.com
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Thursday, November 01, 2012 12:20 PM
To: Zhang, Jun
Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming,
Matt; Paul Gortmaker; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] To crash dump, we need keep other memory type except
E820_RAM, because other type come from BIOS or firmware is used by other
code(for example: PCI_MMCONFIG).
2) would make most sense to me, but I'd be okay with 3) as well.
Zhang, Jun jun.zh...@intel.com wrote:
Hello, Anvin
I want to explain why I modify in this place. In kexec, it pass three
parameters, memmap=exactmap memmap=544K@64K memmap=64964K@32768K I
think my patch modify the least code.
Actually, there are some choise to fix it.
1) my patch.
2) modify kexec, only pass two parameters -- memmap=544K@64K
memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM
range.
3) add extra optional, like memmap=REMOVERAM
Which one do you like? Maybe you have better solution, please share it.
Thanks!
Best Regards!
Jun Zhang
Inet: 8821-4273
Dir.Tel: 86-21-6116-4273
Email: jun.zh...@intel.com
-Original Message-
From: H. Peter Anvin
Re: [PATCH 5/8] ARM: zynq: add COMMON_CLK support
On 11/02/2012 02:38 PM, Josh Cartwright wrote:
Thanks for the review.
On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
On 10/31/2012 07:58 PM, Josh Cartwright wrote:
[...]
+#define PERIPH_CLK_CTRL_SRC(x) (periph_clk_parent_map[((x)3)4])
+#define PERIPH_CLK_CTRL_DIV(x) (((x)0x3F00)8)
A few more spaces wouldn't hurt ;)
Okay, sure.
[...]
+static void __init zynq_periph_clk_setup(struct device_node *np)
+{
+ struct zynq_periph_clk *periph;
+ const char *parent_names[3];
+ struct clk_init_data init;
+ struct clk *clk;
+ int err;
+ u32 reg;
+ int i;
+
+ err = of_property_read_u32(np, reg, reg);
+ WARN_ON(err);
Shouldn't the function abort if a error happens somewhere? Continuing here
will lead to undefined behavior. Same is probably true for the other
WARN_ONs.
The way I see it is: the kernel is will be left in a bad state in the
case of any failure, regardless of if we bail out or continue. AFAICT,
there is no clean way to recover from a failure this early.
Given that, it seems simpler (albeit marginally so) just to continue; so
that's what I chose to do. I'm not opposed to bailing out, just not
convinced it does anything for us.
The issue with this approach is that, while you get a warning, unexpected
seemingly unrelated side-effects may happen later on. E.g. if no reg
property for the clock is specified the reg variable will be uninitialized
and contain whatever was on the stack before. The clock will be registered
nonetheless and the boot process continues. Now if the clock is enabled a
bit in a random register will be modified, which could result in strange and
abnormal behavior, which can be very hard to track down.
Also if for example just one clock has its reg property missing the system
will continue to boot if we bail out here. It is just that the peripherals
using that clock won't work. Which will certainly be easier to diagnose than
random abnormal behavior.
+
+ periph = kzalloc(sizeof(*periph), GFP_KERNEL);
+ WARN_ON(!periph);
+
+ periph-clk_ctrl = slcr_base + reg;
+ spin_lock_init(periph-clkact_lock);
+
+ init.name = np-name;
+ init.ops = zynq_periph_clk_ops;
+ for (i = 0; i ARRAY_SIZE(parent_names); i++)
+ parent_names[i] = of_clk_get_parent_name(np, i);
+ init.parent_names = parent_names;
+ init.num_parents = ARRAY_SIZE(parent_names);
+
+ periph-hw.init = init;
+
+ clk = clk_register(NULL, periph-hw);
+ WARN_ON(IS_ERR(clk));
+
+ err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
+ WARN_ON(err);
+
+ for (i = 0; i 2; i++) {
Not all of the peripheral clock generators have two output clocks. I think
it makes sense to use the number entries in clock-output-names here.
Yes, I agree. I'll also update the bindings documentation.
Thanks again,
Josh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/32] [RFC] nohz/cpuset: Start discussions on nohz CPUs
On Fri, 2012-11-02 at 15:03 +, Christoph Lameter wrote: On Fri, 2 Nov 2012, Steven Rostedt wrote: also it would be best to sync this conceptually with the processors enabled for rcu processing. Processors can be disabled for rcu processing? Or are you talking about Paul's new work of offloading rcu callbacks? Yes. Paul's new work to remove rcu processing from processors. That needs to be synced configuration wise somehow. It does not make sense to process rcu callbacks on processors where the timer tick does not work anymore. Don't worry, Paul is working with us too ;-) -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wakeup latency measured with SCHED_TRACER depends on HZ
On 31.10.2012 22:41, Stanislav Meduna wrote:
on an embedded platform using a Freescale i.MX28 ARM processor
I am experiencing a strange phenomenon - the latencies reported
are dependent of HZ
OK, the problem is that the MXS platform does not setup
the scheduler clock so the scheduler only sees the HZ one.
The patch in attach fixes this. I can only test the MX28 part -
I don't have any timrot_is_v1() (MX23) hardware and I don't
know whether a source that wraps after ~2 seconds is OK at all.
Please Cc: when replying, I am not subscribed to linux-kernel
(only to linux-rt-users).
Regards
--
Stano
From ddeed3c83d48e8ce33b36bd964572756354e7feb Mon Sep 17 00:00:00 2001
From: Stanislav Meduna st...@meduna.org
Date: Fri, 2 Nov 2012 15:00:44 +0100
Subject: [PATCH] Setup scheduler clock for MXS
---
arch/arm/mach-mxs/timer.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mxs/timer.c b/arch/arm/mach-mxs/timer.c
index 564a632..0ab86a2 100644
--- a/arch/arm/mach-mxs/timer.c
+++ b/arch/arm/mach-mxs/timer.c
@@ -26,6 +26,7 @@
#include linux/clk.h
#include asm/mach/time.h
+#include asm/sched_clock.h
#include mach/mxs.h
#include mach/common.h
@@ -243,6 +244,16 @@ static int __init mxs_clocksource_init(struct clk
*timer_clk)
return 0;
}
+static u32 notrace mxs_read_sched_clock_v1(void)
+{
+ return timrotv1_get_cycles(clocksource_mxs);
+}
+
+static u32 notrace mxs_read_sched_clock_v2(void)
+{
+ return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
+}
+
void __init mxs_timer_init(struct clk *timer_clk, int irq)
{
clk_prepare_enable(timer_clk);
@@ -285,6 +296,14 @@ void __init mxs_timer_init(struct clk *timer_clk, int irq)
mxs_clocksource_init(timer_clk);
mxs_clockevent_init(timer_clk);
+ /* Register scheduler clocksource */
+ if (timrot_is_v1())
+ setup_sched_clock(mxs_read_sched_clock_v1,
+ 16, clk_get_rate(timer_clk));
+ else
+ setup_sched_clock(mxs_read_sched_clock_v2,
+ 32, clk_get_rate(timer_clk));
+
/* Make irqs happen */
setup_irq(irq, mxs_timer_irq);
}
--
1.7.0.4
Re: [PATCH 8/9] trace: use this_cpu_ptr per-cpu helper
Christoph Lameter said, at 2012/11/1 1:50: -buffer = per_cpu_ptr(percpu_buffer, smp_processor_id()); +buffer = this_cpu_ptr(percpu_buffer); return buffer-buffer; Just do a return this_cpu_read(percpu_buffer-buffer); and get rid of the this_cpu_ptr op can not do that. kernel/trace/trace.c:1515: error: incompatible types when assigning to type 'char[1024]' from type 'char *' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] vme: vme_tsi148.c: use module_pci_driver to simplify the code
On 18/10/2012 16:12, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Huh, learn something new every day :-)
Acked-by: Martyn Welch martyn.we...@ge.com
Thanks,
Martyn
---
drivers/vme/bridges/vme_tsi148.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 5fbd08f..9c1aa4d 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -35,10 +35,8 @@
#include ../vme_bridge.h
#include vme_tsi148.h
-static int __init tsi148_init(void);
static int tsi148_probe(struct pci_dev *, const struct pci_device_id *);
static void tsi148_remove(struct pci_dev *);
-static void __exit tsi148_exit(void);
/* Module parameter */
@@ -2244,11 +2242,6 @@ static void tsi148_free_consistent(struct device
*parent, size_t size,
pci_free_consistent(pdev, size, vaddr, dma);
}
-static int __init tsi148_init(void)
-{
- return pci_register_driver(tsi148_driver);
-}
-
/*
* Configure CR/CSR space
*
@@ -2754,10 +2747,7 @@ static void tsi148_remove(struct pci_dev *pdev)
kfree(tsi148_bridge);
}
-static void __exit tsi148_exit(void)
-{
- pci_unregister_driver(tsi148_driver);
-}
+module_pci_driver(tsi148_driver);
MODULE_PARM_DESC(err_chk, Check for VME errors on reads and writes);
module_param(err_chk, bool, 0);
@@ -2767,6 +2757,3 @@ module_param(geoid, int, 0);
MODULE_DESCRIPTION(VME driver for the Tundra Tempe VME bridge);
MODULE_LICENSE(GPL);
-
-module_init(tsi148_init);
-module_exit(tsi148_exit);
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] Second attempt at kernel secure boot support
On Wed, Oct 31, 2012 at 03:02:01PM +, Matthew Garrett wrote: On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote: Reading stored memory image (potentially tampered before reboot) from disk is basically DMA-ing arbitrary data over the whole RAM. I am currently not able to imagine a scenario how this could be made secure (without storing private keys to sign the hibernation image on the machine itself which, well, doesn't sound secure either). shim generates a public and private key. It hands the kernel the private key in a boot parameter and stores the public key in a boot variable. On suspend, the kernel signs the suspend image with that private key and discards it. On the next boot, shim generates a new key pair and hands the new private key to the kernel along with the old public key. The kernel verifies the suspend image before resuming it. The only way to subvert this would be to be able to access kernel memory directly, which means the attacker has already won. crash utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] ARM: zynq: add COMMON_CLK support
On Fri, Nov 02, 2012 at 04:12:21PM +0100, Lars-Peter Clausen wrote:
On 11/02/2012 02:38 PM, Josh Cartwright wrote:
On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
On 10/31/2012 07:58 PM, Josh Cartwright wrote:
[...]
+static void __init zynq_periph_clk_setup(struct device_node *np)
+{
+ struct zynq_periph_clk *periph;
+ const char *parent_names[3];
+ struct clk_init_data init;
+ struct clk *clk;
+ int err;
+ u32 reg;
+ int i;
+
+ err = of_property_read_u32(np, reg, reg);
+ WARN_ON(err);
Shouldn't the function abort if a error happens somewhere? Continuing here
will lead to undefined behavior. Same is probably true for the other
WARN_ONs.
The way I see it is: the kernel is will be left in a bad state in the
case of any failure, regardless of if we bail out or continue. AFAICT,
there is no clean way to recover from a failure this early.
Given that, it seems simpler (albeit marginally so) just to continue; so
that's what I chose to do. I'm not opposed to bailing out, just not
convinced it does anything for us.
The issue with this approach is that, while you get a warning, unexpected
seemingly unrelated side-effects may happen later on. E.g. if no reg
property for the clock is specified the reg variable will be uninitialized
and contain whatever was on the stack before. The clock will be registered
nonetheless and the boot process continues. Now if the clock is enabled a
bit in a random register will be modified, which could result in strange and
abnormal behavior, which can be very hard to track down.
Okay.but any reasonable person would start their debugging quest at
the source of the WARN_ON. If someone sees the WARN_ON message but
stupidly chooses to ignore it, they deserves to spend the time trying to
track down abnormal behavior, so I'm still not convinced.
Josh
pgpJcL7YS8kPz.pgp
Description: PGP signature
Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
On Fri, 02 Nov 2012 15:49:02 +0100 Paolo Bonzini pbonz...@redhat.com wrote: Il 31/10/2012 22:22, Tejun Heo ha scritto: Hello, Paolo. On Thu, Oct 25, 2012 at 02:35:20PM -0400, Paolo Bonzini wrote: Disabling filters if opened by root and tranfering via SCM_RIGHTS would be the simplest interface-wise (there's no new interface at all). Would that be too dangerous security-wise? That would be a change with respect to what we have now. After transferring a root-opened (better: CAP_SYS_RAWIO-opened) file descriptor to an unprivileged process your SG_IO commands get filtered. So a ioctl is needed if you want to rely on SCM_RIGHTS. Yeah, I get that it's a behavior change, but would that be a problem? Worse, it's a potential security hole because previously you'd get filtering and now you wouldn't. Considering that SCM_RIGHTS is usually used to transfer a file descriptor from a privileged process to an unprivileged one, I'd be very worried of that. In other contexts you inherit file handles via exec and having a root opened so its special model is bad. Historically it led to things like the rlogin/rsh hacks on SunOS and friends where a program run by the rsh daemon got a root opened socket as its stdin/out and could issue ifconfig ioctls on it at will. Not a good model. Any removal of filters and passing them to a task should be explicit. The behaviour really ought to be to permit the intentional setting of explicit filters then passing them, not touch the default behaviour. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] vme: vme_ca91cx42.c: use module_pci_driver to simplify the code
On 18/10/2012 16:13, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Martyn Welch martyn.we...@ge.com
---
drivers/vme/bridges/vme_ca91cx42.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 1425d22c..64bfea3 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -34,10 +34,8 @@
#include ../vme_bridge.h
#include vme_ca91cx42.h
-static int __init ca91cx42_init(void);
static int ca91cx42_probe(struct pci_dev *, const struct pci_device_id *);
static void ca91cx42_remove(struct pci_dev *);
-static void __exit ca91cx42_exit(void);
/* Module parameters */
static int geoid;
@@ -1523,11 +1521,6 @@ static void ca91cx42_free_consistent(struct device
*parent, size_t size,
pci_free_consistent(pdev, size, vaddr, dma);
}
-static int __init ca91cx42_init(void)
-{
- return pci_register_driver(ca91cx42_driver);
-}
-
/*
* Configure CR/CSR space
*
@@ -1944,16 +1937,10 @@ static void ca91cx42_remove(struct pci_dev *pdev)
kfree(ca91cx42_bridge);
}
-static void __exit ca91cx42_exit(void)
-{
- pci_unregister_driver(ca91cx42_driver);
-}
+module_pci_driver(ca91cx42_driver);
MODULE_PARM_DESC(geoid, Override geographical addressing);
module_param(geoid, int, 0);
MODULE_DESCRIPTION(VME driver for the Tundra Universe II VME bridge);
MODULE_LICENSE(GPL);
-
-module_init(ca91cx42_init);
-module_exit(ca91cx42_exit);
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] vme: vme_vmivme7805.c: use module_pci_driver to simplify the code
On 18/10/2012 16:15, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Martyn Welch martyn.we...@ge.com
---
drivers/vme/boards/vme_vmivme7805.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/boards/vme_vmivme7805.c
b/drivers/vme/boards/vme_vmivme7805.c
index 8e05bb4..dd22b50 100644
--- a/drivers/vme/boards/vme_vmivme7805.c
+++ b/drivers/vme/boards/vme_vmivme7805.c
@@ -19,10 +19,8 @@
#include vme_vmivme7805.h
-static int __init vmic_init(void);
static int vmic_probe(struct pci_dev *, const struct pci_device_id *);
static void vmic_remove(struct pci_dev *);
-static void __exit vmic_exit(void);
/** Base address to access FPGA register */
static void *vmic_base;
@@ -41,11 +39,6 @@ static struct pci_driver vmic_driver = {
.remove = vmic_remove,
};
-static int __init vmic_init(void)
-{
- return pci_register_driver(vmic_driver);
-}
-
static int vmic_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
int retval;
@@ -109,15 +102,9 @@ static void vmic_remove(struct pci_dev *pdev)
}
-static void __exit vmic_exit(void)
-{
- pci_unregister_driver(vmic_driver);
-}
+module_pci_driver(vmic_driver);
MODULE_DESCRIPTION(VMIVME-7805 board support driver);
MODULE_AUTHOR(Arthur Benilov arthur.beni...@iba-group.com);
MODULE_LICENSE(GPL);
-module_init(vmic_init);
-module_exit(vmic_exit);
-
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.we...@ge.com | VAT:GB 927559189
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 31 (ehci, dbgp)
On Fri, Nov 02, 2012 at 10:20:27AM -0400, Alan Stern wrote: On Fri, 2 Nov 2012, Jan Beulich wrote: On 02.11.12 at 15:01, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 1 Nov 2012, Jan Beulich wrote: Alan Stern st...@rowland.harvard.edu 11/01/12 9:39 PM On Thu, 1 Nov 2012, Jan Beulich wrote: Alan Stern st...@rowland.harvard.edu 11/01/12 4:28 PM Evidently we need to change your new test in drivers/usb/early/ehci-dbgp.c to: #if IS_ENABLED(CONFIG_USB_HCD_EHCI) || defined(CONFIG_USB_CHIPIDEA_HOST) Upcoming changes to ehci-hcd will make this unnecessary in 3.8, but for now we need it. Which tells me that the CONFIG_USB_SUPPORT version would have been the better one (and I would favor that over the ugly variant you suggest above). I also suggested IS_ENABLED(CONFIG_USB), which is no uglier than what you submitted and would also fix this build error. How about using it instead? Yes, that's better. Question then is - updated original patch or incremental one? Greg will probably want an incremental patch, because the original has already been merged. I actually sent both (the incremental as attachment - I hope that's going to be acceptable to him) in a submission earlier today. Ah, okay, good. Greg, whichever version you take, you can add: Acked-by: Alan Stern st...@rowland.harvard.edu Thanks for that, as you guessed, I have to take the incremental one as the first is already applied. 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: [RFC] Second attempt at kernel secure boot support
On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: crash utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. That's not upstream, right? -- 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] xen-blk: persistent-grants fixes
This patch contains fixes for persistent grants implementation v2:
* handle == 0 is a valid handle, so initialize grants in blkback
setting the handle to BLKBACK_INVALID_HANDLE instead of 0. Reported
by Konrad Rzeszutek Wilk.
* new_map is a boolean, use true or false instead of 1 and 0.
Reported by Konrad Rzeszutek Wilk.
* blkfront announces the persistent-grants feature as
feature-persistent-grants, use feature-persistent instead which is
consistent with blkback and the public Xen headers.
* Add a consistency check in blkfront to make sure we don't try to
access segments that have not been set.
Signed-off-by: Roger Pau Monne roger@citrix.com
Cc: konrad.w...@oracle.com
Cc: linux-kernel@vger.kernel.org
---
drivers/block/xen-blkback/blkback.c | 15 +--
drivers/block/xen-blkback/xenbus.c |2 +-
drivers/block/xen-blkfront.c|3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 663d42d..a059616 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -503,7 +503,7 @@ static int xen_blkbk_map(struct blkif_request *req,
* We are using persistent grants and
* the grant is already mapped
*/
- new_map = 0;
+ new_map = false;
} else if (use_persistent_gnts
blkif-persistent_gnt_c
max_mapped_grant_pages(blkif-blk_protocol)) {
@@ -511,8 +511,8 @@ static int xen_blkbk_map(struct blkif_request *req,
* We are using persistent grants, the grant is
* not mapped but we have room for it
*/
- new_map = 1;
- persistent_gnt = kzalloc(
+ new_map = true;
+ persistent_gnt = kmalloc(
sizeof(struct persistent_gnt),
GFP_KERNEL);
if (!persistent_gnt)
@@ -523,6 +523,7 @@ static int xen_blkbk_map(struct blkif_request *req,
return -ENOMEM;
}
persistent_gnt-gnt = req-u.rw.seg[i].gref;
+ persistent_gnt-handle = BLKBACK_INVALID_HANDLE;
pages_to_gnt[segs_to_map] =
persistent_gnt-page;
@@ -547,7 +548,7 @@ static int xen_blkbk_map(struct blkif_request *req,
pr_alert(DRV_PFX domain %u, device %#x is
using maximum number of persistent grants\n,
blkif-domid, blkif-vbd.handle);
}
- new_map = 1;
+ new_map = true;
pages[i] = blkbk-pending_page(pending_req, i);
addr = vaddr(pending_req, i);
pages_to_gnt[segs_to_map] =
@@ -584,7 +585,8 @@ static int xen_blkbk_map(struct blkif_request *req,
*/
bitmap_zero(pending_req-unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
for (i = 0, j = 0; i nseg; i++) {
- if (!persistent_gnts[i] || !persistent_gnts[i]-handle) {
+ if (!persistent_gnts[i] ||
+ persistent_gnts[i]-handle == BLKBACK_INVALID_HANDLE) {
/* This is a newly mapped grant */
BUG_ON(j = segs_to_map);
if (unlikely(map[j].status != 0)) {
@@ -601,7 +603,8 @@ static int xen_blkbk_map(struct blkif_request *req,
}
}
if (persistent_gnts[i]) {
- if (!persistent_gnts[i]-handle) {
+ if (persistent_gnts[i]-handle ==
+ BLKBACK_INVALID_HANDLE) {
/*
* If this is a new persistent grant
* save the handler
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index b225026..a03ecbb 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -760,7 +760,7 @@ static int connect_ring(struct backend_info *be)
return -1;
}
err = xenbus_gather(XBT_NIL, dev-otherend,
- feature-persistent-grants, %u,
+ feature-persistent, %u,
pers_grants, NULL);
if (err)
pers_grants = 0;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 911d733..f1de806 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -852,6 +852,7 @@ static void blkif_completion(struct blk_shadow *s, struct
blkfront_info
[GIT PULL] (xen) stable/for-linus-3.7-rc4-tag
Hey Linus, Please git pull the following tag: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc4-tag which has the following fixes (copy-n-paste from the signed tag): tag Bug-fixes: * Use appropriate macros instead of hand-rolling our own (ARM). * Fixes if FB/KBD closed unexpectedly. * Fix memory leak in /dev/gntdev ioctl calls. * Fix overflow check in xenbus_file_write. * Document cleanup. * Performance optimization when migrating guests. /tag Nothing major - rather just incremental fixes. arch/arm/xen/hypercall.S | 14 + arch/x86/include/asm/xen/hypervisor.h| 1 - arch/x86/xen/mmu.c | 21 ++- drivers/input/misc/xen-kbdfront.c| 5 - drivers/video/xen-fbfront.c | 5 - drivers/xen/gntdev.c | 36 +--- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- include/trace/events/xen.h | 8 +++ 8 files changed, 61 insertions(+), 31 deletions(-) David Vrabel (3): xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF xen-fbfront: handle backend CLOSED without CLOSING xen-kbdfront: handle backend CLOSED without CLOSING Jan Beulich (1): xen/xenbus: fix overflow check in xenbus_file_write() Konrad Rzeszutek Wilk (1): xen/mmu: Use Xen specific TLB flush instead of the generic one. Olaf Hering (1): x86: remove obsolete comment from asm/xen/hypervisor.h Stefano Stabellini (1): xen/arm: use the __HVC macro pgp9XOlKU9Fjh.pgp Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: On 11/01/2012 02:27 PM, Pavel Machek wrote: Could someone write down exact requirements for Linux kernel to be signed by Microsoft? Because thats apparently what you want, and I don't think crippling kexec/suspend is enough. As I understand it, the kernel won't be signed by Microsoft. Rather, the bootloader will be signed by Microsoft and the vendors will be the ones that refuse to sign a kernel unless it is reasonably assured that it won't be used as an attack vector. If you want fully-open behaviour it's still possible, you just need to turn off secure boot. With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Yep, good in theory. Now that basically means reimplementing kexec-tools in kernel. That also means creating a new system call. It also also means cutting down on future flexibility (assuming new system call interface will be able to support existing features provided by kernel). And it is lot of code in user space which needs to be reimplemented in kernel and bloat kernel. Keeping most of the logic in kexec-tools provided flexibility and keeps kernel small. So now re-architect kexec and reverse a good design completely for secureboot. It is a huge pain. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] TTY: move tty buffers to tty_port
On 10/31/2012 04:59 PM, Sasha Levin wrote: So you probably want a lot more than 100k syscalls, why limit it at all actually? I unset the limit but I still can't reproduce... I've attached my .config for the guest kernel as reference. Even using this config does not help to reproduce that. Do you use some special trinity params? thanks, -- js suse labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Fri, Nov 02, 2012 at 03:42:48PM +, Matthew Garrett wrote: On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: crash utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. That's not upstream, right? Yes, checked with Dave, it is not upstream. Well, still it is a concern for distro kernel. So if we keep private key in kernel, looks like we shall have to disable one more feature in secureboot mode. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next] ARM64: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-10-26 at 09:23 -0600, Shuah Khan wrote:
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan shuah.k...@hp.com
Acked-by: Catalin Marinas catalin.mari...@arm.com
Do you want this patch going through linux-next or the ARM64 tree? Let
me know your preference.
-- Shuah
---
arch/arm64/include/asm/dma-mapping.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index 538f4b4..9947768 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -50,6 +50,7 @@ static inline phys_addr_t dma_to_phys(struct device *dev,
dma_addr_t dev_addr)
static inline int dma_mapping_error(struct device *dev, dma_addr_t dev_addr)
{
struct dma_map_ops *ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dev_addr);
return ops-mapping_error(dev, dev_addr);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/9 v2] use efficient this_cpu_* helper
this_cpu_ptr is faster than per_cpu_ptr(p, smp_processor_id()) and can reduce memory accesses. The latter helper needs to find the offset for current cpu, and needs more assembler instructions which objdump shows in following. per_cpu_ptr(p, smp_processor_id())： 1e: 65 8b 04 25 00 00 00 00 mov%gs:0x0,%eax 26: 48 98 cltq 28: 31 f6 xor%esi,%esi 2a: 48 c7 c7 00 00 00 00mov$0x0,%rdi 31: 48 8b 04 c5 00 00 00 00 mov0x0(,%rax,8),%rax 39: c7 44 10 04 14 00 00 00 movl $0x14,0x4(%rax,%rdx,1) this_cpu_ptr(p) 1e: 65 48 03 14 25 00 00 00 00 add%gs:0x0,%rdx 27: 31 f6 xor%esi,%esi 29: c7 42 04 14 00 00 00movl $0x14,0x4(%rdx) 30: 48 c7 c7 00 00 00 00mov$0x0,%rdi Changelog V2: 1. Use this_cpu_read directly instead of ref to field of per-cpu variable. 2. Patch5 about ftrace is dropped from this series. 3. Add new patch9 to replace get_cpu;per_cpu_ptr;put_cpu with this_cpu_add opt. 4. For preemption disable case, use __this_cpu_read instead. $ git diff --stat b77bc2069d1e437d5a1a71bb5cfcf4556ee40015 drivers/clocksource/arm_generic.c |2 +- kernel/padata.c |5 ++--- kernel/rcutree.c |2 +- kernel/trace/blktrace.c |2 +- kernel/trace/trace.c |4 +--- net/batman-adv/main.h |4 +--- net/core/flow.c |4 +--- net/openvswitch/datapath.c|4 ++-- net/openvswitch/vport.c |5 ++--- net/rds/ib_recv.c |2 +- net/xfrm/xfrm_ipcomp.c|7 +++ 11 files changed, 16 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/9] net: rds: use this_cpu_ptr per-cpu helper
From: Shan Wei davids...@tencent.com Signed-off-by: Shan Wei davids...@tencent.com Reviewed-by: Christoph Lameter c...@linux.com --- net/rds/ib_recv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c index 8d19491..a4a5064 100644 --- a/net/rds/ib_recv.c +++ b/net/rds/ib_recv.c @@ -423,7 +423,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item, local_irq_save(flags); - chp = per_cpu_ptr(cache-percpu, smp_processor_id()); + chp = this_cpu_ptr(cache-percpu); if (!chp-first) INIT_LIST_HEAD(new_item); else /* put on front */ -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/9] net: xfrm: use __this_cpu_read per-cpu helper
From: Shan Wei davids...@tencent.com
Signed-off-by: Shan Wei davids...@tencent.com
---
net/xfrm/xfrm_ipcomp.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
index e5246fb..394d672 100644
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -276,14 +276,13 @@ static struct crypto_comp * __percpu
*ipcomp_alloc_tfms(const char *alg_name)
struct crypto_comp * __percpu *tfms;
int cpu;
- /* This can be any valid CPU ID so we don't need locking. */
- cpu = raw_smp_processor_id();
-
list_for_each_entry(pos, ipcomp_tfms_list, list) {
struct crypto_comp *tfm;
tfms = pos-tfms;
- tfm = *per_cpu_ptr(tfms, cpu);
+
+ /* This can be any valid CPU ID so we don't need locking. */
+ tfm = __this_cpu_read(tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos-users++;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Shan Wei davids...@tencent.com
no change vs v1.
Lots of drivers use this kind to read/write per-cpu variable.
stats = this_cpu_ptr(dp-stats_percpu);
u64_stats_update_begin(stats-sync);
stats-tx_packets++;
u64_stats_update_begin(stats-sync);
Signed-off-by: Shan Wei davids...@tencent.com
---
net/openvswitch/datapath.c |4 ++--
net/openvswitch/vport.c|5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4c4b62c..77d16a5 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -208,7 +208,7 @@ void ovs_dp_process_received_packet(struct vport *p, struct
sk_buff *skb)
int error;
int key_len;
- stats = per_cpu_ptr(dp-stats_percpu, smp_processor_id());
+ stats = this_cpu_ptr(dp-stats_percpu);
/* Extract flow from 'skb' into 'key'. */
error = ovs_flow_extract(skb, p-port_no, key, key_len);
@@ -282,7 +282,7 @@ int ovs_dp_upcall(struct datapath *dp, struct sk_buff *skb,
return 0;
err:
- stats = per_cpu_ptr(dp-stats_percpu, smp_processor_id());
+ stats = this_cpu_ptr(dp-stats_percpu);
u64_stats_update_begin(stats-sync);
stats-n_lost++;
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 03779e8..70af0be 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -333,8 +333,7 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff
*skb)
{
struct vport_percpu_stats *stats;
- stats = per_cpu_ptr(vport-percpu_stats, smp_processor_id());
-
+ stats = this_cpu_ptr(vport-percpu_stats);
u64_stats_update_begin(stats-sync);
stats-rx_packets++;
stats-rx_bytes += skb-len;
@@ -359,7 +358,7 @@ int ovs_vport_send(struct vport *vport, struct sk_buff *skb)
if (likely(sent)) {
struct vport_percpu_stats *stats;
- stats = per_cpu_ptr(vport-percpu_stats, smp_processor_id());
+ stats = this_cpu_ptr(vport-percpu_stats);
u64_stats_update_begin(stats-sync);
stats-tx_packets++;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/9] kernel: padata : use this_cpu_read per-cpu helper
From: Shan Wei davids...@tencent.com
Signed-off-by: Shan Wei davids...@tencent.com
---
kernel/padata.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 89fe3d1..cf94137 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -171,7 +171,7 @@ static struct padata_priv *padata_get_next(struct
parallel_data *pd)
{
int cpu, num_cpus;
unsigned int next_nr, next_index;
- struct padata_parallel_queue *queue, *next_queue;
+ struct padata_parallel_queue *next_queue;
struct padata_priv *padata;
struct padata_list *reorder;
@@ -204,8 +204,7 @@ static struct padata_priv *padata_get_next(struct
parallel_data *pd)
goto out;
}
- queue = per_cpu_ptr(pd-pqueue, smp_processor_id());
- if (queue-cpu_index == next_queue-cpu_index) {
+ if (this_cpu_read(pd-pqueue-cpu_index) == next_queue-cpu_index) {
padata = ERR_PTR(-ENODATA);
goto out;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/9] rcu: use __this_cpu_read helper instead of per_cpu_ptr(p, raw_smp_processor_id())
From: Shan Wei davids...@tencent.com
Signed-off-by: Shan Wei davids...@tencent.com
---
kernel/rcutree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 74df86b..441b945 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1960,7 +1960,7 @@ static void force_quiescent_state(struct rcu_state *rsp)
struct rcu_node *rnp_old = NULL;
/* Funnel through hierarchy to reduce memory contention. */
- rnp = per_cpu_ptr(rsp-rda, raw_smp_processor_id())-mynode;
+ rnp = __this_cpu_read(rsp-rda-mynode);
for (; rnp != NULL; rnp = rnp-parent) {
ret = (ACCESS_ONCE(rsp-gp_flags) RCU_GP_FLAG_FQS) ||
!raw_spin_trylock(rnp-fqslock);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/9] trace: use this_cpu_ptr per-cpu helper
From: Shan Wei davids...@tencent.com Signed-off-by: Shan Wei davids...@tencent.com --- kernel/trace/blktrace.c |2 +- kernel/trace/trace.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index c0bd030..71259e2 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c @@ -147,7 +147,7 @@ void __trace_note_message(struct blk_trace *bt, const char *fmt, ...) return; local_irq_save(flags); - buf = per_cpu_ptr(bt-msg_data, smp_processor_id()); + buf = this_cpu_ptr(bt-msg_data); va_start(args, fmt); n = vscnprintf(buf, BLK_TN_MAX_MSG, fmt, args); va_end(args); diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 31e4f55..81ae35b 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -1513,7 +1513,7 @@ static char *get_trace_buf(void) if (!percpu_buffer) return NULL; - buffer = per_cpu_ptr(percpu_buffer, smp_processor_id()); + buffer = this_cpu_ptr(percpu_buffer); return buffer-buffer; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 8/9] clocksource: use this_cpu_ptr per-cpu helper
From: Shan Wei davids...@tencent.com Signed-off-by: Shan Wei davids...@tencent.com Reviewed-by: Christoph Lameter c...@linux.com --- drivers/clocksource/arm_generic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/clocksource/arm_generic.c b/drivers/clocksource/arm_generic.c index c4d9f95..cb445ab 100644 --- a/drivers/clocksource/arm_generic.c +++ b/drivers/clocksource/arm_generic.c @@ -224,7 +224,7 @@ int __init arm_generic_timer_init(void) lpj_fine = arch_timer_rate / HZ; /* Immediately configure the timer on the boot CPU */ - arch_timer_setup(per_cpu_ptr(arch_timer_evt, smp_processor_id())); + arch_timer_setup(this_cpu_ptr(arch_timer_evt)); register_cpu_notifier(arch_timer_cpu_nb); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] net: batman-adv: use per_cpu_add helper
From: Shan Wei davids...@tencent.com
As Christoph Lameter said:
In addition, following usage of per_cpu_ptr can be replaced by this_cpu_read.
cpu=get_cpu()
*per_cpu_ptr(p,cpu)
put_cpu()
Right.
Signed-off-by: Shan Wei davids...@tencent.com
---
net/batman-adv/main.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 897ba6a..3aef5b2 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -263,9 +263,7 @@ static inline bool batadv_has_timed_out(unsigned long
timestamp,
static inline void batadv_add_counter(struct batadv_priv *bat_priv, size_t idx,
size_t count)
{
- int cpu = get_cpu();
- per_cpu_ptr(bat_priv-bat_counters, cpu)[idx] += count;
- put_cpu();
+ this_cpu_add(bat_priv-bat_counters[idx], count);
}
#define batadv_inc_counter(b, i) batadv_add_counter(b, i, 1)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9 v2] use efficient this_cpu_* helper
this_cpu_ptr is faster than per_cpu_ptr(p, smp_processor_id()) and can reduce memory accesses. The latter helper needs to find the offset for current cpu, and needs more assembler instructions which objdump shows in following. per_cpu_ptr(p, smp_processor_id())： 1e: 65 8b 04 25 00 00 00 00 mov%gs:0x0,%eax 26: 48 98 cltq 28: 31 f6 xor%esi,%esi 2a: 48 c7 c7 00 00 00 00mov$0x0,%rdi 31: 48 8b 04 c5 00 00 00 00 mov0x0(,%rax,8),%rax 39: c7 44 10 04 14 00 00 00 movl $0x14,0x4(%rax,%rdx,1) this_cpu_ptr(p) 1e: 65 48 03 14 25 00 00 00 00 add%gs:0x0,%rdx 27: 31 f6 xor%esi,%esi 29: c7 42 04 14 00 00 00movl $0x14,0x4(%rdx) 30: 48 c7 c7 00 00 00 00mov$0x0,%rdi Changelog V2: 1. Use this_cpu_read directly instead of ref to field of per-cpu variable. 2. Patch5 about ftrace is dropped from this series. 3. Add new patch9 to replace get_cpu;per_cpu_ptr;put_cpu with this_cpu_add opt. 4. For preemption disable case, use __this_cpu_read instead. $ git diff --stat b77bc2069d1e437d5a1a71bb5cfcf4556ee40015 drivers/clocksource/arm_generic.c |2 +- kernel/padata.c |5 ++--- kernel/rcutree.c |2 +- kernel/trace/blktrace.c |2 +- kernel/trace/trace.c |4 +--- net/batman-adv/main.h |4 +--- net/core/flow.c |4 +--- net/openvswitch/datapath.c|4 ++-- net/openvswitch/vport.c |5 ++--- net/rds/ib_recv.c |2 +- net/xfrm/xfrm_ipcomp.c|7 +++ 11 files changed, 16 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Shan Wei davids...@tencent.com
Signed-off-by: Shan Wei davids...@tencent.com
Reviewed-by: Christoph Lameter c...@linux.com
---
net/core/flow.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index e318c7e..3bad824 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
static void flow_cache_flush_per_cpu(void *data)
{
struct flow_flush_info *info = data;
- int cpu;
struct tasklet_struct *tasklet;
- cpu = smp_processor_id();
- tasklet = per_cpu_ptr(info-cache-percpu, cpu)-flush_tasklet;
+ tasklet = this_cpu_ptr(info-cache-percpu)-flush_tasklet;
tasklet-data = (unsigned long)info;
tasklet_schedule(tasklet);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Fair enough. But there's no such thing a 'hotplug enumeration construct' in Linux yet, and a bus is the closest thing to it. It does take advantage of the nice way device code matches drivers and devices though. A bus is the wrong construct. You need something to add devices onto the busses. You can do that. The Intel SFI layer on phones for example enumerates devices through a firmware table set and creates them on the right actual physical bus not on their own fake one. Physically, it is a bus, though it is made up of several other busses. While I could certainly see people using the mechanism for enumerating soldered-down devices over the fixed busses, there is a physical connector that deserves some abstraction/identification. Further, it is critical to enable hardware vendors to avoid writing any code for which there are existing drivers. It's not hotplug in the sense that the phone happens be a fixed configuration but it does support hotplug behaviour because the order of the drivers and enumeration is undefined (and both orders work). I think SFI is interesting, but certainly lacks all of the interfaces. It seems reasonable to me to extend the specification to add the missing interfaces, but what doesn't seem to map is the fact that the SFI structures are initially processed in the bootloader and passed statically to the kernel, rather than enabling run-time operation. Users may make run-time trade-offs and also need mechanisms for performing initial debug on products like proto capes. Capebus seems to me to provide this solution fairly well. I don't believe the SFI approach covers the most critical aspects of hotplug behaviour. I'm afraid that having the I2C/SPI drivers doing the detection won't work. The capes can have arbitrary I2C/SPI devices (and even more weird components). There is no way to assure for example that the I2C device responding to address 'foo' in cape A is the same I2C device responding to the same address in cape B. your -detect() method should take care of that. There isn't some magical serial number in I²C devices that a -detect() method can read and the implementation of I²C is somewhat It doesn't matter. What you are basically talking about is cape layer - wtf is this - how do I plumb it - create device nodes with correct name for binding, address etc on the right bus i2c layer - ooh a new i2c device - probe as indicated by device name - attach correct driver Many of the devices cannot be probed. Architecturally its possible you want to make some caps MFDs if they have their own bus heirarchies etc but generally I doubt it. Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of a platform which parses tables and attaches devices to the right physical bus in a manner they can be reliably probed even when the device has no sane autodetect. I know I *am* the slow person in the room, but doesn't this approach require the code to be compiled into the kernel to support the devices ahead of time? While I think it might be reasonable to have hardware developers provide DT fragments in their EEPROMs, there's no way to get them to submit code patches in order to get their hardware to work. They need to ship hardware that works with pre-existing software, since there will be hundreds of boards created by people with little to no previous Linux experience (akin to Arduino). I seem to be missing how that approach would get us there. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] TTY: move tty buffers to tty_port
On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby jsl...@suse.cz wrote: On 10/31/2012 04:59 PM, Sasha Levin wrote: So you probably want a lot more than 100k syscalls, why limit it at all actually? I unset the limit but I still can't reproduce... I've attached my .config for the guest kernel as reference. Even using this config does not help to reproduce that. Do you use some special trinity params? Not really: ./trinity -m --quiet --dangerous -l off Can I add something to my kernel to provide more info when it happens? Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: add support for zsmalloc and zcache
On Fri, Oct 26, 2012 at 04:45:14PM -0500, Seth Jennings wrote: On 10/02/2012 01:17 PM, Dan Magenheimer wrote: If so, shake hands and move forward? What do you see as next steps? I've been reviewing the changes between zcache and zcache2 and getting a feel for the scope and direction of those changes. - Getting the community engaged to review zcache1 at ~2300SLOC was difficult. - Adding RAMSter has meant adding RAMSter-specific code broadly across zcache and increases the size of code to review to ~7600SLOC. One can ignore the drivers/staging/ramster/ramster* directory. - The changes have blurred zcache's internal layering and increased complexity beyond what a simple SLOC metric can reflect. Not sure I see a problem. - Getting the community engaged in reviewing zcache2 will be difficult and will require an exceptional amount of effort for maintainer and reviewer. Exceptional? I think if we start trimming the code down and moving it around - and moving the 'ramster' specific calls to header files to not be compiled - that should make it easier to read. I mean the goal of any review is to address all of the concern you saw when you were looking over the code. You probably have a page of questions you asked yourself - and in all likehood the other reviewers would ask the same questions. So if you address them - either by giving comments or making the code easier to read - that would do it. It is difficult for me to know when it could be ready for mainline and production use. While zcache2 isn't getting broad code reviews yet, how do suggest managing that complexity to make the code maintainable and get it reviewed? There are Mel's feedback that is also applicable to zcache2. Thanks for looking at the code! Seth -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] percpu_rw_semaphore: reimplement to not block the readers unnecessarily
On 11/01, Oleg Nesterov wrote:
On 11/01, Paul E. McKenney wrote:
OK, so it looks to me that this code relies on synchronize_sched()
forcing a memory barrier on each CPU executing in the kernel.
No, the patch tries to avoid this assumption, but probably I missed
something.
1. A task running on CPU 0 currently write-holds the lock.
2. CPU 1 is running in the kernel, executing a longer-than-average
loop of normal instructions (no atomic instructions or memory
barriers).
3. CPU 0 invokes percpu_up_write(), calling up_write(),
synchronize_sched(), and finally mutex_unlock().
And my expectation was, this should be enough because ...
4. CPU 1 executes percpu_down_read(), which calls update_fast_ctr(),
since update_fast_ctr does preempt_disable/enable it should see all
modifications done by CPU 0.
IOW. Suppose that the writer (CPU 0) does
percpu_done_write();
STORE;
percpu_up_write();
This means
STORE;
synchronize_sched();
mutex_unlock();
Now. Do you mean that the next preempt_disable/enable can see the
result of mutex_unlock() but not STORE?
So far I think this is not possible, so the code doesn't need the
additional wstate/barriers.
+static bool update_fast_ctr(struct percpu_rw_semaphore *brw, int val)
+{
+ bool success = false;
int state;
+
+ preempt_disable();
+ if (likely(!mutex_is_locked(brw-writer_mutex))) {
state = ACCESS_ONCE(brw-wstate);
if (likely(!state)) {
+ __this_cpu_add(*brw-fast_read_ctr, val);
+ success = true;
} else if (state WSTATE_NEED_MB) {
__this_cpu_add(*brw-fast_read_ctr, val);
smb_mb(); /* Order increment against critical section. */
success = true;
}
...
+void percpu_up_write(struct percpu_rw_semaphore *brw)
+{
+ /* allow the new readers, but only the slow-path */
+ up_write(brw-rw_sem);
ACCESS_ONCE(brw-wstate) = WSTATE_NEED_MB;
+
+ /* insert the barrier before the next fast-path in down_read */
+ synchronize_sched();
But update_fast_ctr() should see mutex_is_locked(), obiously down_write()
must ensure this.
So update_fast_ctr() can execute the WSTATE_NEED_MB code only if it
races with
ACCESS_ONCE(brw-wstate) = 0;
+ mutex_unlock(brw-writer_mutex);
these 2 stores and sees them in reverse order.
I guess that mutex_is_locked() in update_fast_ctr() looks a bit confusing.
It means no-fast-path for the reader, we could use -state instead.
And even -writer_mutex should go away if we want to optimize the
write-contended case, but I think this needs another patch on top of
this initial implementation.
Oleg.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] TTY: move tty buffers to tty_port
On 11/02/2012 05:07 PM, Sasha Levin wrote: On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby jsl...@suse.cz wrote: On 10/31/2012 04:59 PM, Sasha Levin wrote: So you probably want a lot more than 100k syscalls, why limit it at all actually? I unset the limit but I still can't reproduce... I've attached my .config for the guest kernel as reference. Even using this config does not help to reproduce that. Do you use some special trinity params? Not really: ./trinity -m --quiet --dangerous -l off Oh, you run that as root?? Can I add something to my kernel to provide more info when it happens? Maybe the attached patch can tell us more... -- js suse labs From 36ad8f281846ef395e1969fc2af324c5edb13043 Mon Sep 17 00:00:00 2001 From: Jiri Slaby jsl...@suse.cz Date: Sun, 28 Oct 2012 21:42:02 +0100 Subject: [PATCH] tty BUF DEBUG Signed-off-by: Jiri Slaby jsl...@suse.cz --- drivers/tty/tty_buffer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index 45d9161..c70274b 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c @@ -371,6 +371,7 @@ void tty_schedule_flip(struct tty_struct *tty) if (buf-tail != NULL) buf-tail-commit = buf-tail-used; spin_unlock_irqrestore(buf-lock, flags); + WARN_RATELIMIT(tty-port-itty == NULL, HUH\n); schedule_work(buf-work); } EXPORT_SYMBOL(tty_schedule_flip); @@ -566,6 +567,7 @@ void tty_flip_buffer_push(struct tty_struct *tty) buf-tail-commit = buf-tail-used; spin_unlock_irqrestore(buf-lock, flags); + WARN_RATELIMIT(tty-port-itty == NULL, HUH\n); if (tty-low_latency) flush_to_ldisc(buf-work); else -- 1.8.0
[RFC PATCH 1/2] memory: davinci - add aemif controller platform driver
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at init time. A set of APIs (set/get) provided to
update the values based on specific driver usage.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/arm/davinci/aemif.txt | 62 +++
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 397
include/linux/platform_data/davinci-aemif.h| 47 +++
5 files changed, 517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
create mode 100644 drivers/memory/davinci-aemif.c
create mode 100644 include/linux/platform_data/davinci-aemif.h
diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt
b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
new file mode 100644
index 000..7d70d42
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
@@ -0,0 +1,62 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif chip select
+bindings.
+
+This is a sub device node inside the davinci-emif device node
+to describe a async bus for a specific chip select. For NAND,
+CFI flash device bindings described inside an aemif node,
+etc, a cs sub node is defined to associate the bus parameter
+bindings used by the device.
+
+Required properties:=
+- compatible: ti,davinci-cs;
+- #address-cells = 1;
+- #size-cells = 1;
+- cs - cs used by the device (NAND, CFI flash etc. values in the range: 2-5
+
+Optional properties:-
+- asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+ All of the params below in nanoseconds
+
+- ta - Minimum turn around time
+- rhold - read hold width
+- rstobe - read strobe width
+- rsetup - read setup width
+- whold - write hold width
+- wstrobe - write strobe width
+- wsetup - write setup width
+- ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ew - enable/disable extended wait cycles (0 - disable, 1 - enable)
+
+Example for davinci nand chip select
+
+aemif@6000 {
+
+ compatible = ti,davinci-aemif;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ nand_cs:cs2@7000 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ cs = 2;
+ asize = 1;
+ ta = 24;
+ rhold = 48;
+ rstrobe = 390;
+ rsetup = 96;
+ whold = 48;
+ wstrobe = 390;
+ wsetup = 96;
+ };
+
+ nand@2,0 {
+
+
+
+ };
+};
+
+
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..2636a95 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -40,4 +40,14 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config TI_DAVINCI_AEMIF
+ bool Texas Instruments DaVinci AEMIF driver
+ help
+ This driver is for the AEMIF module available in Texas Instruments
+ SoCs. AEMIF stands for Asynchronous External Memory Interface and
+ is intended to provide a glue-less interface to a variety of
+ asynchronuous memory devices like ASRAM, NOR and NAND memory. A total
+ of 256M bytes of any of these memories can be accessed at a given
+ time via four chip selects with 64M byte access per chip select.
+
endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..246aa61 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_TI_EMIF) += emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
+obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
new file mode 100644
index 000..6c42116
--- /dev/null
+++ b/drivers/memory/davinci-aemif.c
@@ -0,0 +1,397 @@
+/*
+ * AEMIF support for DaVinci SoCs
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/
+ * Copyright (C) Heiko Schocher h...@denx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
[RFC PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
DaVinci NAND driver is a controller driver based on the AEMIF hardware
IP found on TI SoCs. It is also used on SoCs that are not DaVinci based. This
patch removes the driver dependency on DaVinci architecture so that it
can be used on other architectures such as c6x, keystone etc.
Also migrate the driver to use the new AEMIF platform driver API.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/mtd/nand/Kconfig |6 +-
drivers/mtd/nand/davinci_nand.c| 40 ++---
include/linux/platform_data/davinci-nand.h | 87
3 files changed, 107 insertions(+), 26 deletions(-)
create mode 100644 include/linux/platform_data/davinci-nand.h
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8ca4176..390cc95 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -569,11 +569,11 @@ config MTD_NAND_SH_FLCTL
for NAND Flash using FLCTL.
config MTD_NAND_DAVINCI
-tristate Support NAND on DaVinci SoC
-depends on ARCH_DAVINCI
+tristate Support NAND on SoCs with AEMIF
+ select TI_DAVINCI_AEMIF
help
Enable the driver for NAND flash chips on Texas Instruments
- DaVinci processors.
+ SoCs that has Asynchronous External Memory Interface (AEMIF).
config MTD_NAND_TXX9NDFMC
tristate NAND Flash support for TXx9 SoC
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 321b053..306959e 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -35,8 +35,8 @@
#include linux/slab.h
#include linux/of_device.h
-#include mach/nand.h
-#include mach/aemif.h
+#include linux/platform_data/davinci-nand.h
+#include linux/platform_data/davinci-aemif.h
/*
* This is a device driver for the NAND flash controller found on the
@@ -73,7 +73,7 @@ struct davinci_nand_info {
uint32_tcore_chipsel;
- struct davinci_aemif_timing *timing;
+ struct davinci_aemif_cs_data*cs_data;
};
static DEFINE_SPINLOCK(davinci_nand_lock);
@@ -652,7 +652,6 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
info-chip.options = pdata-options;
info-chip.bbt_td = pdata-bbt_td;
info-chip.bbt_md = pdata-bbt_md;
- info-timing= pdata-timing;
info-ioaddr= (uint32_t __force) vaddr;
@@ -731,26 +730,21 @@ static int __init nand_davinci_probe(struct
platform_device *pdev)
goto err_clk_enable;
}
- /*
-* Setup Async configuration register in case we did not boot from
-* NAND and so bootloader did not bother to set it up.
-*/
- val = davinci_nand_readl(info, A1CR_OFFSET + info-core_chipsel * 4);
-
- /* Extended Wait is not valid and Select Strobe mode is not used */
- val = ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
- if (info-chip.options NAND_BUSWIDTH_16)
- val |= 0x1;
+ if (info-chip.options NAND_BUSWIDTH_16) {
+ info-cs_data =
+ davinci_aemif_get_abus_params(info-core_chipsel);
+ if (info-cs_data == NULL)
+ goto err_bus_config;
- davinci_nand_writel(info, A1CR_OFFSET + info-core_chipsel * 4, val);
+ /* asize = 1 for 16bit bus */
+ info-cs_data-asize = 1;
+ ret = davinci_aemif_set_abus_params(info-core_chipsel,
+ info-cs_data);
- ret = 0;
- if (info-timing)
- ret = davinci_aemif_setup_timing(info-timing, info-base,
- info-core_chipsel);
- if (ret 0) {
- dev_dbg(pdev-dev, NAND timing values setup fail\n);
- goto err_timing;
+ if (ret 0) {
+ dev_dbg(pdev-dev, NAND timing values setup fail\n);
+ goto err_bus_config;
+ }
}
spin_lock_irq(davinci_nand_lock);
@@ -841,7 +835,7 @@ syndrome_done:
return 0;
err_scan:
-err_timing:
+err_bus_config:
clk_disable_unprepare(info-clk);
err_clk_enable:
diff --git a/include/linux/platform_data/davinci-nand.h
b/include/linux/platform_data/davinci-nand.h
new file mode 100644
index 000..df1fc66
--- /dev/null
+++ b/include/linux/platform_data/davinci-nand.h
@@ -0,0 +1,87 @@
+/*
+ * mach-davinci/nand.h
+ *
+ * Copyright © 2006 Texas Instruments.
+ *
+ * Ported to 2.6.23 Copyright © 2008 by
+ * Sander Huijsen shuij...@optelecom-nkf.com
+ * Troy Kisky troy.ki...@boundarydevices.com
+ * Dirk Behme dirk.be...@gmail.com
+ *
+ * --
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as
Re: [PATCH v3 0/7] Improve swiotlb performance by using physical addresses
On Mon, Oct 29, 2012 at 03:05:56PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Oct 29, 2012 at 11:18:09AM -0700, Alexander Duyck wrote: On Mon, Oct 15, 2012 at 10:19 AM, Alexander Duyck alexander.h.du...@intel.com wrote: While working on 10Gb/s routing performance I found a significant amount of time was being spent in the swiotlb DMA handler. Further digging found that a significant amount of this was due to virtual to physical address translation and calling the function that did it. It accounted for nearly 60% of the total swiotlb overhead. This patch set works to resolve that by replacing the io_tlb_start and io_tlb_end virtual addresses with a physical addresses. In addition it changes the io_tlb_overflow_buffer from a virtual to a physical address. I followed through with the cleanup to the point that the only functions that really require the virtual address for the DMA buffer are the init, free, and bounce functions. In the case of devices that are using the bounce buffers these patches should result in only a slight performance gain if any. This is due to the locking overhead required to map and unmap the buffers. In the case of devices that are not making use of bounce buffers these patches can significantly reduce their overhead. In the case of an ixgbe routing test for example, these changes result in 7 fewer calls to __phys_addr and allow is_swiotlb_buffer to become inlined due to a reduction in the number of instructions. When running a routing throughput test using small packets I saw roughly a 6% increase in packets rates after applying these patches. This appears to match up with the CPU overhead reduction I was tracking via perf. Before: Results 10.0Mpps After: Results 10.6Mpps Finally, I updated the parameter names for several of the core function calls as there was some ambiguity in naming. Specifically virtual address pointers were named dma_addr. When I changed these pointers to physical I instead used the name tlb_addr as this value represented a physical address in the io_tlb_start region and is less likely to be confused with a bus address. v2: I reviewed the changes and realized that the first patch that was dropping io_tlb_end and calculating the value didn't actually gain me much once I had gone through and translated the rest of the addresses to physical addresses. As such I have updated the patch so that it instead is converting io_tlb_end from a virtual address to a physical address. This actually helps to reduce the overhead for is_swiotlb_buffer and swiotlb_dma_supported by several instructions. v3: After reviewing the patches I realized I was causing some namespace pollution since a static char * was being replaced with phys_addr_t when it should have been static phys_addr_t. As such I have updated the first 3 patches to correctly replace static pointers with static physical addresses. --- Alexander Duyck (7): swiotlb: Do not export swiotlb_bounce since there are no external consumers swiotlb: Use physical addresses instead of virtual in swiotlb_tbl_sync_single swiotlb: Use physical addresses for swiotlb_tbl_unmap_single swiotlb: Return physical addresses when calling swiotlb_tbl_map_single swiotlb: Make io_tlb_overflow_buffer a physical address swiotlb: Make io_tlb_start a physical address instead of a virtual one swiotlb: Make io_tlb_end a physical address instead of a virtual one drivers/xen/swiotlb-xen.c | 25 ++-- include/linux/swiotlb.h | 20 ++- lib/swiotlb.c | 269 +++-- 3 files changed, 163 insertions(+), 151 deletions(-) Is there any ETA on when this patch series might be pulled into a tree? I'm just wondering if I need to rebase this patch series and resubmit it, and if so what tree I need to rebase it off of? No need to rebase it. I did a test on V2 version with Xen, but I still need to do a IA64/Calgary/AMD Vi/Intel VT-d/GART test before pushing it out. So you should your patches in linux-next. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] - Move AEMIF driver out of DaVinci machine
The DaVinci AEMIF (asynchronous external memory interface) is used on other TI SoCs that are not DaVinci based. So the AEMIF driver is to be moved outside mach-davinci to the drivers folder so that it can be re-used on other TI SoCs. Also migrate the DaVinci NAND driver to use the new aemif API. Some of these code has been borrowed from intial patch from Heiko Schocher h...@denx.de. So I have added his name in the Copyright for davinci-aemif.c This is an RFC to get the intial response so that all the platforms can be migrated to use this driver. Murali Karicheri (2): memory: davinci - add aemif controller platform driver mtd: davinci - remove DaVinci architecture depedency .../devicetree/bindings/arm/davinci/aemif.txt | 62 +++ drivers/memory/Kconfig | 10 + drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 397 drivers/mtd/nand/Kconfig |6 +- drivers/mtd/nand/davinci_nand.c| 40 +- include/linux/platform_data/davinci-aemif.h| 47 +++ include/linux/platform_data/davinci-nand.h | 87 + 8 files changed, 624 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt create mode 100644 drivers/memory/davinci-aemif.c create mode 100644 include/linux/platform_data/davinci-aemif.h create mode 100644 include/linux/platform_data/davinci-nand.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Fri, 2 Nov 2012, Vivek Goyal wrote: crash utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. That's not upstream, right? Yes, checked with Dave, it is not upstream. Well, still it is a concern for distro kernel. Well, that's about /dev/crash, right? How about /proc/kcore? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Further, it is critical to enable hardware vendors to avoid writing any code for which there are existing drivers. Which is why you don't want to create a new bus type for it. Capebus seems to me to provide this solution fairly well. I don't believe the SFI approach covers the most critical aspects of hotplug behaviour. I think you missed the point - it just an example of doing this not one I'd suggest using directly. your -detect() method should take care of that. There isn't some magical serial number in I²C devices that a -detect() method can read and the implementation of I²C is somewhat It doesn't matter. What you are basically talking about is cape layer - wtf is this - how do I plumb it - create device nodes with correct name for binding, address etc on the right bus i2c layer - ooh a new i2c device - probe as indicated by device name - attach correct driver Many of the devices cannot be probed. Look more closely at the code I pointed you at. I wonder if have a differing understanding of the word probe in this situation. In the Linux space the driver bindings call the matching probe function based upon the device structure. In Linux the probe method does not mean scan the bus and enumerate/detect the devices If an i²c bus is thrown a device which has an address and a matching name the only thing it will attempt to do is to call the probe method of the device driver matching that name on the given i²c address. In other words its a probe in the sense of I've been told there is one of your widgets here, please take a look not a probe in the sense of scan 255 i²c addresses and poke randomly at them SFI for example creates entries for things like type foo pressure sensor at 0x68 on bus 3 and the core kernel i²c code will only call the foo drivers probe method and only on bus 3 and only for address 0x68. In your case you want to use your DT fragments or any other descriptor format to do exactly the same. Not create a new bus but add a bunch of devices to the existing busses. It's like hot plugging a PCI card - you don't create a new PCI bus, you add a device to the existing bus. In the PCI case the device has properties that uniquely identify it from hardware level. In the i²c case the properties come from your DT fragment or similar. The rest is the same. I know I *am* the slow person in the room, but doesn't this approach require the code to be compiled into the kernel to support the devices ahead of time? While I think it might be reasonable to have hardware The specific implementation in SFI does but thats a property of SFI. I'm not trying to push SFI itself anywhere except over the edge of a very tall cliff. The point is that you can take a description of things like i²c devices and have then properly identified on the existing busses using the existing bus architecture just fine. developers provide DT fragments in their EEPROMs, there's no way to get them to submit code patches in order to get their hardware to work. They need to ship hardware that works with pre-existing software, since there will be hundreds of boards created by people with little to no previous Linux experience (akin to Arduino). I seem to be missing how that approach would get us there. That is what I assume and what I believe can be provided without inventing imaginary bus types. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 21/21] TTY: move tty buffers to tty_port
On 11/02/2012 12:18 PM, Jiri Slaby wrote: On 11/02/2012 05:07 PM, Sasha Levin wrote: On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby jsl...@suse.cz wrote: On 10/31/2012 04:59 PM, Sasha Levin wrote: So you probably want a lot more than 100k syscalls, why limit it at all actually? I unset the limit but I still can't reproduce... I've attached my .config for the guest kernel as reference. Even using this config does not help to reproduce that. Do you use some special trinity params? Not really: ./trinity -m --quiet --dangerous -l off Oh, you run that as root?? Yup, it runs inside a disposable VM. Thanks, Sasha -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Thu 2012-11-01 15:02:25, Chris Friesen wrote: On 11/01/2012 02:27 PM, Pavel Machek wrote: Could someone write down exact requirements for Linux kernel to be signed by Microsoft? Because thats apparently what you want, and I don't think crippling kexec/suspend is enough. As I understand it, the kernel won't be signed by Microsoft. Rather, the bootloader will be signed by Microsoft and the vendors will be the ones that refuse to sign a kernel unless it is reasonably assured that it won't be used as an attack vector. Yes. So can someone write down what used as an attack vector means? Because, AFAICT, Linux kernel is _designed_ to work as an attact vector. We intentionally support wine, and want to keep that support. With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Also the kernel would need to sign its suspend-to-disk images and refuse to resume unsigned images. I believe that attacking Windows using wine is easier than using suspend-to-disk. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 v2] mm: print out information of file affected by memory error
Printing out the information about which file can be affected by a
memory error in generic_error_remove_page() is helpful for user to
estimate the impact of the error.
Changelog v2:
- dereference mapping-host after if (!mapping) check for robustness
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: Jan Kara j...@suse.cz
---
mm/truncate.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git v3.7-rc3.orig/mm/truncate.c v3.7-rc3/mm/truncate.c
index d51ce92..db1b216 100644
--- v3.7-rc3.orig/mm/truncate.c
+++ v3.7-rc3/mm/truncate.c
@@ -151,14 +151,20 @@ int truncate_inode_page(struct address_space *mapping,
struct page *page)
*/
int generic_error_remove_page(struct address_space *mapping, struct page *page)
{
+ struct inode *inode;
+
if (!mapping)
return -EINVAL;
+ inode = mapping-host;
/*
* Only punch for normal data pages for now.
* Handling other types like directories would need more auditing.
*/
- if (!S_ISREG(mapping-host-i_mode))
+ if (!S_ISREG(inode-i_mode))
return -EIO;
+ pr_info(MCE %#lx: file info pgoff:%lu, inode:%lu, dev:%s\n,
+ page_to_pfn(page), page_index(page),
+ inode-i_ino, inode-i_sb-s_id);
return truncate_inode_page(mapping, page);
}
EXPORT_SYMBOL(generic_error_remove_page);
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 v2] HWPOISON: fix action_result() to print out dirty/clean
action_result() fails to print out dirty even if an error occurred on a
dirty pagecache, because when we check PageDirty in action_result() it was
cleared after page isolation even if it's dirty before error handling. This
can break some applications that monitor this message, so should be fixed.
There are several callers of action_result() except page_action(), but
either of them are not for LRU pages but for free pages or kernel pages,
so we don't have to consider dirty or not for them.
Note that PG_dirty can be set outside page locks as described in commit
554940dc8c1e, so this patch does not completely closes the race window,
but just narrows it.
Changelog v2:
- Add comment about setting PG_dirty outside page lock
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Reviewed-by: Andi Kleen a...@linux.intel.com
---
mm/memory-failure.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git v3.7-rc3.orig/mm/memory-failure.c v3.7-rc3/mm/memory-failure.c
index 6c5899b..4377de9 100644
--- v3.7-rc3.orig/mm/memory-failure.c
+++ v3.7-rc3/mm/memory-failure.c
@@ -781,16 +781,16 @@ static struct page_state {
{ compound, compound, huge, me_huge_page },
#endif
- { sc|dirty, sc|dirty, swapcache,me_swapcache_dirty },
- { sc|dirty, sc, swapcache,me_swapcache_clean },
+ { sc|dirty, sc|dirty, dirty swapcache,
me_swapcache_dirty },
+ { sc|dirty, sc, clean swapcache,
me_swapcache_clean },
- { unevict|dirty, unevict|dirty, unevictable LRU, me_pagecache_dirty},
- { unevict, unevict,unevictable LRU, me_pagecache_clean},
+ { unevict|dirty, unevict|dirty, dirty unevictable LRU,
me_pagecache_dirty },
+ { unevict, unevict,clean unevictable LRU,
me_pagecache_clean },
- { mlock|dirty, mlock|dirty,mlocked LRU, me_pagecache_dirty },
- { mlock,mlock, mlocked LRU, me_pagecache_clean },
+ { mlock|dirty, mlock|dirty,dirty mlocked LRU,
me_pagecache_dirty },
+ { mlock,mlock, clean mlocked LRU,
me_pagecache_clean },
- { lru|dirty,lru|dirty, LRU, me_pagecache_dirty },
+ { lru|dirty,lru|dirty, dirty LRU,me_pagecache_dirty },
{ lru|dirty,lru,clean LRU,me_pagecache_clean },
/*
@@ -812,14 +812,14 @@ static struct page_state {
#undef slab
#undef reserved
+/*
+ * Dirty/Clean indication is not 100% accurate due to the possibility of
+ * setting PG_dirty outside page lock. See also comment above set_page_dirty().
+ */
static void action_result(unsigned long pfn, char *msg, int result)
{
- struct page *page = pfn_to_page(pfn);
-
- printk(KERN_ERR MCE %#lx: %s%s page recovery: %s\n,
- pfn,
- PageDirty(page) ? dirty : ,
- msg, action_name[result]);
+ pr_err(MCE %#lx: %s page recovery: %s\n,
+ pfn, msg, action_name[result]);
}
static int page_action(struct page_state *ps, struct page *p,
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] HWPOISON: improve logging
Hello, These 2 patches fix or add the kernel messages which help users to know what kind of pages are hit by errors and/or how the impact is. Originally these were posted as part of patchsets which are pending due to unsolved issues, but these are simple enough and related only to memory error handling (no change on IO error handling,) so I think these 2 can be separated from whole things and go into mainline first. Thanks, Naoya -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Second attempt at kernel secure boot support
On Fri, Nov 2, 2012 at 9:52 AM, Vivek Goyal vgo...@redhat.com wrote: On Fri, Nov 02, 2012 at 03:42:48PM +, Matthew Garrett wrote: On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: crash utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. That's not upstream, right? Yes, checked with Dave, it is not upstream. Well, still it is a concern for distro kernel. So if we keep private key in kernel, looks like we shall have to disable one more feature in secureboot mode. I have been following parts of this thread and beginning to think, Are we over engineering the solution for secureboot. Do we have a list of what is must to meet the Spec.? At this point, Linux secureboot solution is sounding so pervasive and will impact every aspect of Linux user's and kernel developer's use pattern. So far I picked up on the following: Kernel need to be signed. firmware kernel loads needs to be signed What else? Is there a list of what all needs to be signed? I am interested in seeing a list of requirements. At some point, OS will be so secure that, will it become so complex to run anything on it and continue to do development as we are used to doing today? I don't pretend to know much about secureboot, and I am asking as a concerned Linux user, and kernel developer. -- Shuah -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [Xen-devel] [PATCH] xen/hvm: If we fail to fetch an HVM parameter print out which flag it is.
On Tue, Oct 23, 2012 at 10:22:18AM +0100, Ian Campbell wrote:
On Fri, 2012-10-19 at 20:03 +0100, Konrad Rzeszutek Wilk wrote:
Makes it easier to troubleshoot in the field.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
include/xen/hvm.h | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index b193fa2..c2a4238 100644
--- a/include/xen/hvm.h
+++ b/include/xen/hvm.h
@@ -5,6 +5,33 @@
#include xen/interface/hvm/params.h
#include asm/xen/hypercall.h
+static const char *param_name(int op)
+{
+ static const char *const names[] = {
#define PARAM(x) [x] = STRINGIFY(x)
would save from typos due to doubling everything up.
Or even:
#define PARAM(x) [HVM_PARAM#_x] STRINGIFY(x)
+ [HVM_PARAM_CALLBACK_IRQ] = HVM_PARAM_CALLBACK_IRQ,
+ [HVM_PARAM_STORE_PFN] = HVM_PARAM_STORE_PFN,
+ [HVM_PARAM_STORE_EVTCHN] = HVM_PARAM_STORE_EVTCHN,
+ [HVM_PARAM_PAE_ENABLED] = HVM_PARAM_PAE_ENABLED,
+ [HVM_PARAM_IOREQ_PFN] = HVM_PARAM_IOREQ_PFN,
+ [HVM_PARAM_BUFIOREQ_PFN] = HVM_PARAM_BUFIOREQ_PFN,
+ [HVM_PARAM_TIMER_MODE] = HVM_PARAM_TIMER_MODE,
+ [HVM_PARAM_HPET_ENABLED] = HVM_PARAM_HPET_ENABLED,
+ [HVM_PARAM_IDENT_PT] = HVM_PARAM_IDENT_PT,
+ [HVM_PARAM_DM_DOMAIN] = HVM_PARAM_DM_DOMAIN,
+ [HVM_PARAM_ACPI_S_STATE] = HVM_PARAM_ACPI_S_STATE,
+ [HVM_PARAM_VM86_TSS] = HVM_PARAM_VM86_TSS,
+ [HVM_PARAM_VPT_ALIGN] = HVM_PARAM_VPT_ALIGN,
+ [HVM_PARAM_CONSOLE_PFN] = HVM_PARAM_CONSOLE_PFN,
+ [HVM_PARAM_CONSOLE_EVTCHN] = HVM_PARAM_CONSOLE_EVTCHN };
You probably want a , and a newline before the }.
+
+ if (op = ARRAY_SIZE(names))
+ return unknown;
+
+ if (!names[op])
+ return reserved;
+
+ return names[op];
+}
static inline int hvm_get_parameter(int idx, uint64_t *value)
{
struct xen_hvm_param xhv;
@@ -14,8 +41,8 @@ static inline int hvm_get_parameter(int idx, uint64_t
*value)
xhv.index = idx;
r = HYPERVISOR_hvm_op(HVMOP_get_param, xhv);
if (r 0) {
- printk(KERN_ERR Cannot get hvm parameter %d: %d!\n,
- idx, r);
+ printk(KERN_ERR Cannot get hvm parameter %s (%d): %d!\n,
+ param_name(idx), idx, r);
return r;
}
*value = xhv.value;
Like this?
From 66705b0ff8808d86c12fcb3815d849a848b5409b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Fri, 19 Oct 2012 15:01:46 -0400
Subject: [PATCH] xen/hvm: If we fail to fetch an HVM parameter print out
which flag it is.
Makes it easier to troubleshoot in the field.
[v1: Use macro per Ian's suggestion]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
include/xen/hvm.h | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index b193fa2..13e43e4 100644
--- a/include/xen/hvm.h
+++ b/include/xen/hvm.h
@@ -5,6 +5,36 @@
#include xen/interface/hvm/params.h
#include asm/xen/hypercall.h
+static const char *param_name(int op)
+{
+#define PARAM(x) [HVM_PARAM_##x] = #x
+ static const char *const names[] = {
+ PARAM(CALLBACK_IRQ),
+ PARAM(STORE_PFN),
+ PARAM(STORE_EVTCHN),
+ PARAM(PAE_ENABLED),
+ PARAM(IOREQ_PFN),
+ PARAM(BUFIOREQ_PFN),
+ PARAM(TIMER_MODE),
+ PARAM(HPET_ENABLED),
+ PARAM(IDENT_PT),
+ PARAM(DM_DOMAIN),
+ PARAM(ACPI_S_STATE),
+ PARAM(VM86_TSS),
+ PARAM(VPT_ALIGN),
+ PARAM(CONSOLE_PFN),
+ PARAM(CONSOLE_EVTCHN),
+ };
+#undef PARAM
+
+ if (op = ARRAY_SIZE(names))
+ return unknown;
+
+ if (!names[op])
+ return reserved;
+
+ return names[op];
+}
static inline int hvm_get_parameter(int idx, uint64_t *value)
{
struct xen_hvm_param xhv;
@@ -14,8 +44,8 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
xhv.index = idx;
r = HYPERVISOR_hvm_op(HVMOP_get_param, xhv);
if (r 0) {
- printk(KERN_ERR Cannot get hvm parameter %d: %d!\n,
- idx, r);
+ printk(KERN_ERR Cannot get hvm parameter %s (%d): %d!\n,
+ param_name(idx), idx, r);
return r;
}
*value = xhv.value;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).
On 11/01/2012 01:49 AM, Zhang, Jun wrote: Hello, Anvin Thank for your advice. Hello, All the next patch is made by 2), please review it. Thanks! No, it is not. You are still modifying the behavior of the kernel depending on CONFIG_CRASH_DUMP. CONFIG_CRASH_DUMP doesn't mean we are doing a crash dump. It means it is possible to use this kernel to do a crash dump. Either you are using standard kernel parameters in a standard way which is what option 2 was supposed to be -- it should require no kernel changes! -- or you have to put something in a code path specific to a crash dump. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX] PCI/PM: Fix proc config reg access for D3cold and bridge suspending
On Wed, Oct 24, 2012 at 7:36 PM, Huang Ying ying.hu...@intel.com wrote:
In
https://bugzilla.kernel.org/show_bug.cgi?id=48981
Peter reported that /proc/bus/pci/??/??.? does not works for 3.6.
This is This is because the device configuration space registers will
be not accessible if the corresponding parent bridge is suspended or
the device is put into D3cold state.
This is the same as /sys/bus/pci/devices/:??:??.?/config access
issue. So the function used to solve sysfs issue is used to solve
this issue.
Cc: sta...@vger.kernel.org
Reported-by: Peter lekenst...@gmail.com
Is this bug the same as the one originally reported by Forrest Loomis
(original reporter of bug 48981)? And
https://bugzilla.kernel.org/show_bug.cgi?id=49031, reported by Micael
Dias (Rafael marked 49031 as a duplicate of 48981)?
If so, I'll mention Forrest and Micael and bug 49031 here as well.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
drivers/pci/pci-sysfs.c | 34 --
drivers/pci/pci.c | 32
drivers/pci/pci.h |2 ++
drivers/pci/proc.c |8
4 files changed, 42 insertions(+), 34 deletions(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -458,40 +458,6 @@ boot_vga_show(struct device *dev, struct
}
struct device_attribute vga_attr = __ATTR_RO(boot_vga);
-static void
-pci_config_pm_runtime_get(struct pci_dev *pdev)
-{
- struct device *dev = pdev-dev;
- struct device *parent = dev-parent;
-
- if (parent)
- pm_runtime_get_sync(parent);
- pm_runtime_get_noresume(dev);
- /*
-* pdev-current_state is set to PCI_D3cold during suspending,
-* so wait until suspending completes
-*/
- pm_runtime_barrier(dev);
- /*
-* Only need to resume devices in D3cold, because config
-* registers are still accessible for devices suspended but
-* not in D3cold.
-*/
- if (pdev-current_state == PCI_D3cold)
- pm_runtime_resume(dev);
-}
-
-static void
-pci_config_pm_runtime_put(struct pci_dev *pdev)
-{
- struct device *dev = pdev-dev;
- struct device *parent = dev-parent;
-
- pm_runtime_put(dev);
- if (parent)
- pm_runtime_put_sync(parent);
-}
-
static ssize_t
pci_read_config(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1858,6 +1858,38 @@ bool pci_dev_run_wake(struct pci_dev *de
}
EXPORT_SYMBOL_GPL(pci_dev_run_wake);
+void pci_config_pm_runtime_get(struct pci_dev *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device *parent = dev-parent;
+
+ if (parent)
+ pm_runtime_get_sync(parent);
+ pm_runtime_get_noresume(dev);
+ /*
+* pdev-current_state is set to PCI_D3cold during suspending,
+* so wait until suspending completes
+*/
+ pm_runtime_barrier(dev);
+ /*
+* Only need to resume devices in D3cold, because config
+* registers are still accessible for devices suspended but
+* not in D3cold.
+*/
+ if (pdev-current_state == PCI_D3cold)
+ pm_runtime_resume(dev);
+}
+
+void pci_config_pm_runtime_put(struct pci_dev *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device *parent = dev-parent;
+
+ pm_runtime_put(dev);
+ if (parent)
+ pm_runtime_put_sync(parent);
+}
+
/**
* pci_pm_init - Initialize PM functions of given PCI device
* @dev: PCI device to handle.
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -72,6 +72,8 @@ extern void pci_disable_enabled_device(s
extern int pci_finish_runtime_suspend(struct pci_dev *dev);
extern int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
extern void pci_wakeup_bus(struct pci_bus *bus);
+extern void pci_config_pm_runtime_get(struct pci_dev *dev);
+extern void pci_config_pm_runtime_put(struct pci_dev *dev);
extern void pci_pm_init(struct pci_dev *dev);
extern void platform_pci_wakeup_init(struct pci_dev *dev);
extern void pci_allocate_cap_save_buffers(struct pci_dev *dev);
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -76,6 +76,8 @@ proc_bus_pci_read(struct file *file, cha
if (!access_ok(VERIFY_WRITE, buf, cnt))
return -EINVAL;
+ pci_config_pm_runtime_get(dev);
+
if ((pos 1) cnt) {
unsigned char val;
pci_user_read_config_byte(dev, pos, val);
@@ -121,6 +123,8 @@ proc_bus_pci_read(struct file *file, cha
cnt--;
}
+ pci_config_pm_runtime_put(dev);
+
*ppos = pos;
return nbytes;
}
@@ -146,6 +150,8 @@ proc_bus_pci_write(struct file *file, co
if (!access_ok(VERIFY_READ, buf, cnt))
Re: [PATCH 1/2] xen/hypercall: fix hypercall fallback code for very old hypervisors
On Wed, Oct 31, 2012 at 08:55:54AM +, Jan Beulich wrote:
On 30.10.12 at 16:44, Konrad Rzeszutek Wilk konrad.w...@oracle.com
wrote:
On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
From: Jan Beulich jbeul...@suse.com
While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly rc) which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).
Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Jan Beulich jbeul...@suse.com
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
And it looks like I get
ERROR: HYPERVISOR_event_channel_op_compat [drivers/xen/xen-evtchn.ko]
undefined!
when I build xen-evtchn as module. Jan did you encounter this issue on
2.6.18?
No - the event channel driver there can't be built as a module, and
for the forward ported kernels I apparently never tried to build with
a compat setting of 3.0.2 or less (and I didn't care that much either
because the oldest we're actually concerned about is 3.0.4 to cover
some of those very old EC2 systems; I'll add the export at the right
point nevertheless).
Ok, ended up with this version which I was thinking to for v3.7-rc5:
From 4ae4c7658a7c0501521c422d618038587c3edeca Mon Sep 17 00:00:00 2001
From: Jan Beulich jbeul...@suse.com
Date: Fri, 19 Oct 2012 15:25:37 -0400
Subject: [PATCH] xen/hypercall: fix hypercall fallback code for very old
hypervisors
While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly rc) which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).
Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Jan Beulich jbeul...@suse.com
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
[v3: Fix compile errors when modules use said hypercalls]
[v4: Add xen_ prefix to the HYPERCALL_..]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/include/asm/xen/hypercall.h | 21 --
drivers/xen/Makefile | 2 +-
drivers/xen/fallback.c | 81
3 files changed, 89 insertions(+), 15 deletions(-)
create mode 100644 drivers/xen/fallback.c
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..4055421 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t
new_val,
return _hypercall4(int, update_va_mapping, va,
new_val.pte, new_val.pte 32, flags);
}
+extern int __must_check xen_HYPERVISOR_event_channel_op_compat(int, void *);
static inline int
HYPERVISOR_event_channel_op(int cmd, void *arg)
{
int rc = _hypercall2(int, event_channel_op, cmd, arg);
- if (unlikely(rc == -ENOSYS)) {
- struct evtchn_op op;
- op.cmd = cmd;
- memcpy(op.u, arg, sizeof(op.u));
- rc = _hypercall1(int, event_channel_op_compat, op);
- memcpy(arg, op.u, sizeof(op.u));
- }
+ if (unlikely(rc == -ENOSYS))
+ rc = xen_HYPERVISOR_event_channel_op_compat(cmd, arg);
return rc;
}
@@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
return _hypercall3(int, console_io, cmd, count, str);
}
+extern int __must_check xen_HYPERVISOR_physdev_op_compat(int, void *);
+
static inline int
HYPERVISOR_physdev_op(int cmd, void *arg)
{
int rc = _hypercall2(int, physdev_op, cmd, arg);
- if (unlikely(rc == -ENOSYS)) {
- struct physdev_op op;
- op.cmd = cmd;
- memcpy(op.u, arg, sizeof(op.u));
- rc =
Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-10-26 at 09:40 -0600, Shuah Khan wrote:
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan shuah.k...@hp.com
---
arch/c6x/include/asm/dma-mapping.h |1 +
1 file changed, 1 insertion(+)
Would you like to this patch go through c6x arch tree or linux-next?
Please let me know your preference.
-- Shuah
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index 03579fd..3c69406 100644
--- a/arch/c6x/include/asm/dma-mapping.h
+++ b/arch/c6x/include/asm/dma-mapping.h
@@ -32,6 +32,7 @@ static inline int dma_set_mask(struct device *dev, u64
dma_mask)
*/
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
+ debug_dma_mapping_error(dev, dma_addr);
return dma_addr == ~0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote: browse through various detect functions, yes, some of them key off an ID, but a lot of them just check various registers to see if certain bits are zero, or certain bits are one. A lot of I²C devices I've dealt with have no good way of probing them, especially GPIO chips (you'll notice none of the I²C GPIO expanders have detect functions) it doesn't mean it can't be done. Really? Please, do tell how you would write a detect function for a PCA9534. It has 4 registers, an input port registers, an output port register, a polarity inversion register, and a configuration register. read them and match to their reset values, perhaps ? So its ok for it to not work on warm reset? Also, I'm pretty sure [ random, 0xff, 0x00, 0xff ] describes quite a few chips. And don't forget, since we are probing, every detect routine for every I²C driver will have to run with every I²C address on every bus, possibly with both address formats. not *every* I2C address. What you say is wrong, a -detect() method will only run for those addresses which the device can actually assume. OK, that's still a potentially large number of addresses. On top of all this the detect routine does not tell you if the alert pin is connected to some IRQ, or in the case of a GPIO expander, what those GPIOs are connected to, etc, etc. so what ? All you want to do with detect is figure out if the far end is who you think it is, not what it's doing. If we already knew who was there, we wouldn't need a detect routine. of course not :-) But the whole discussion has been about not knowing which capes (and thus which devices) are attached to the bone. Eh? Finding out which bone is connected is pretty easy, they all have an EEPROM with identifying information. That isn't the problem that capebus is solving, capebus is solving the problem of enumerating that hardware. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] perf: powerpc: Use uapi/unistd.h to fix build error
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Date: Wed, 31 Oct 2012 11:21:28 -0700 Subject: [PATCH] perf: powerpc: Use uapi/unistd.h to fix build error Use the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool. Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com --- tools/perf/perf.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/perf/perf.h b/tools/perf/perf.h index 054182e..f4952da 100644 --- a/tools/perf/perf.h +++ b/tools/perf/perf.h @@ -26,7 +26,7 @@ void get_term_dimensions(struct winsize *ws); #endif #ifdef __powerpc__ -#include ../../arch/powerpc/include/asm/unistd.h +#include ../../arch/powerpc/include/uapi/asm/unistd.h #define rmb() asm volatile (sync ::: memory) #define cpu_relax()asm volatile ( ::: memory); #define CPUINFO_PROC cpu -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT RESEND linux-next] hexagon: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-10-26 at 09:43 -0600, Shuah Khan wrote:
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan shuah.k...@hp.com
---
arch/hexagon/include/asm/dma-mapping.h |1 +
1 file changed, 1 insertion(+)
Would you like se this patch go through arch tree or linux-next? Please
let me know your preference.
-- Shuah
diff --git a/arch/hexagon/include/asm/dma-mapping.h
b/arch/hexagon/include/asm/dma-mapping.h
index 85e9935..1957c4c 100644
--- a/arch/hexagon/include/asm/dma-mapping.h
+++ b/arch/hexagon/include/asm/dma-mapping.h
@@ -65,6 +65,7 @@ static inline int dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dma_addr);
if (dma_ops-mapping_error)
return dma_ops-mapping_error(dev, dma_addr);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
Hey, Alan, Paolo. On Fri, Nov 02, 2012 at 03:35:30PM +, Alan Cox wrote: That would be a change with respect to what we have now. After transferring a root-opened (better: CAP_SYS_RAWIO-opened) file descriptor to an unprivileged process your SG_IO commands get filtered. So a ioctl is needed if you want to rely on SCM_RIGHTS. Yeah, I get that it's a behavior change, but would that be a problem? Worse, it's a potential security hole because previously you'd get filtering and now you wouldn't. Considering that SCM_RIGHTS is usually used to transfer a file descriptor from a privileged process to an unprivileged one, I'd be very worried of that. In other contexts you inherit file handles via exec and having a root opened so its special model is bad. Historically it led to things like the rlogin/rsh hacks on SunOS and friends where a program run by the rsh daemon got a root opened socket as its stdin/out and could issue ifconfig ioctls on it at will. Not a good model. Any removal of filters and passing them to a task should be explicit. The behaviour really ought to be to permit the intentional setting of explicit filters then passing them, not touch the default behaviour. Yeah, well, then I guess it'll have to be a separate ioctl to switch SG_IO for !root users. 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: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
On Thu, Nov 01, 2012 at 06:34:45AM +, Liu, Jinsong wrote:
Thanks! updated as attached.
Jinsong
=
From f514b97628945cfac00efb0d456f133d44754c9d Mon Sep 17 00:00:00 2001
From: Liu, Jinsong jinsong@intel.com
Date: Thu, 1 Nov 2012 21:02:36 +0800
Subject: [PATCH 1/2] Xen acpi pad implement
PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.
This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and very thin logic level, would take over acpi pad staff.
When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
and then hypercall to hyervisor for the rest work, say, core parking.
Two comments:
- Did you look at the SuSE tree? Jan mentioned that they did some
fixes? Did you carry them over?
- The init function should not make hypercalls before checking if it
in facts run under Xen.
Signed-off-by: Liu, Jinsong jinsong@intel.com
---
drivers/xen/Makefile |1 +
drivers/xen/xen_acpi_pad.c | 206
++
include/xen/interface/platform.h | 17 +++
3 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 drivers/xen/xen_acpi_pad.c
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..a2af622 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG) += mcelog.o
obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/
obj-$(CONFIG_XEN_PRIVCMD)+= xen-privcmd.o
obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
+obj-$(CONFIG_XEN_DOM0) += xen_acpi_pad.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
xen-gntalloc-y := gntalloc.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 000..e8c26a4
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,206 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *Author: Liu, Jinsong jinsong@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include acpi/acpi_bus.h
+#include acpi/acpi_drivers.h
+#include asm/xen/hypercall.h
+#include xen/interface/version.h
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS acpi_pad
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME Processor Aggregator
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+static DEFINE_MUTEX(xen_pad_lock);
+
+static int xen_pad_set_idle_cpus(int num_cpus)
+{
+ struct xen_platform_op op;
+
+ if (num_cpus 0)
+ return -EINVAL;
+
+ /* set cpu nums expected to be idled */
+ op.cmd = XENPF_core_parking;
+ op.u.core_parking.type = XEN_CORE_PARKING_SET;
+ op.u.core_parking.idle_nums = num_cpus;
+
+ return HYPERVISOR_dom0_op(op);
+}
+
+/*
+ * Cannot get idle cpus by using hypercall once (shared with _SET)
+ * because of the characteristic of Xen continue_hypercall_on_cpu
+ */
+static int xen_pad_get_idle_cpus(void)
+{
+ int ret;
+ struct xen_platform_op op;
+
+ /* get cpu nums actually be idled */
+ op.cmd = XENPF_core_parking;
+ op.u.core_parking.type = XEN_CORE_PARKING_GET;
+ ret = HYPERVISOR_dom0_op(op);
+ if (ret 0)
+ return ret;
+
+ return op.u.core_parking.idle_nums;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+ struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+ union acpi_object *package;
+ int num = -1;
+
+ if (ACPI_FAILURE(acpi_evaluate_object(handle, _PUR, NULL, buffer)))
+ return num;
+
+ if (!buffer.length || !buffer.pointer)
+ return num;
+
+ package = buffer.pointer;
+
+ if (package-type == ACPI_TYPE_PACKAGE
+ package-package.count == 2
+ package-package.elements[0].integer.value == 1) /* rev 1 */
+
+ num = package-package.elements[1].integer.value;
+
+ kfree(buffer.pointer);
+ return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void
Re: [BUGFIX 1/2] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
If a PCI device and its parents are put into D3cold, unbinding the
device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
- device_lock(dev) --- previous lock here
- __device_release_driver
- pm_runtime_get_sync
...
- rpm_resume(dev)
- rpm_resume(dev-parent)
...
- pci_pm_runtime_resume
...
- pci_set_power_state
- __pci_start_power_transition
- pci_wakeup_bus(dev-parent-subordinate)
- pci_walk_bus
- device_lock(dev)--- dead lock here
If we do not do device_lock in pci_walk_bus, we can avoid dead lock.
Device_lock in pci_walk_bus is introduced in commit:
d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin
said device_lock is added to pci_walk_bus because:
Some error handling functions call pci_walk_bus. For example, PCIe
aer. Here we lock the device, so the driver wouldn't detach from the
device, as the cb might call driver's callback function.
So I fixed the dead lock as follow:
- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback
I checked pci_walk_bus users one by one, and found only PCIe aer needs
device lock.
Is there a problem report or bugzilla for this issue?
Signed-off-by: Huang Ying ying.hu...@intel.com
Cc: Zhang Yanmin yanmin.zh...@intel.com
Should this go to stable as well? The D3cold support appeared in
v3.6, so my guess is that this fix could go to v3.6.x.
---
drivers/pci/bus.c |3 ---
drivers/pci/pcie/aer/aerdrv_core.c | 20
2 files changed, 16 insertions(+), 7 deletions(-)
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -320,10 +320,7 @@ void pci_walk_bus(struct pci_bus *top, i
} else
next = dev-bus_list.next;
- /* Run device routines with the device locked */
- device_lock(dev-dev);
retval = cb(dev, userdata);
- device_unlock(dev-dev);
if (retval)
break;
}
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -213,6 +213,7 @@ static int report_error_detected(struct
struct aer_broadcast_data *result_data;
result_data = (struct aer_broadcast_data *) data;
+ device_lock(dev-dev);
dev-error_state = result_data-state;
if (!dev-driver ||
@@ -231,12 +232,14 @@ static int report_error_detected(struct
dev-driver ?
no AER-aware driver : no driver);
}
- return 0;
+ goto out;
}
err_handler = dev-driver-err_handler;
vote = err_handler-error_detected(dev, result_data-state);
result_data-result = merge_result(result_data-result, vote);
+out:
+ device_unlock(dev-dev);
return 0;
}
@@ -247,14 +250,17 @@ static int report_mmio_enabled(struct pc
struct aer_broadcast_data *result_data;
result_data = (struct aer_broadcast_data *) data;
+ device_lock(dev-dev);
if (!dev-driver ||
!dev-driver-err_handler ||
!dev-driver-err_handler-mmio_enabled)
- return 0;
+ goto out;
err_handler = dev-driver-err_handler;
vote = err_handler-mmio_enabled(dev);
result_data-result = merge_result(result_data-result, vote);
+out:
+ device_unlock(dev-dev);
return 0;
}
@@ -265,14 +271,17 @@ static int report_slot_reset(struct pci_
struct aer_broadcast_data *result_data;
result_data = (struct aer_broadcast_data *) data;
+ device_lock(dev-dev);
if (!dev-driver ||
!dev-driver-err_handler ||
!dev-driver-err_handler-slot_reset)
- return 0;
+ goto out;
err_handler = dev-driver-err_handler;
vote = err_handler-slot_reset(dev);
result_data-result = merge_result(result_data-result, vote);
+out:
+ device_unlock(dev-dev);
return 0;
}
@@ -280,15 +289,18 @@ static int report_resume(struct pci_dev
{
const struct pci_error_handlers *err_handler;
+ device_lock(dev-dev);
dev-error_state = pci_channel_io_normal;
if (!dev-driver ||
!dev-driver-err_handler ||
!dev-driver-err_handler-resume)
- return 0;
+ goto out;
err_handler = dev-driver-err_handler;
Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
Hey, Paolo. On Fri, Nov 02, 2012 at 03:49:02PM +0100, Paolo Bonzini wrote: Yeah, I get that it's a behavior change, but would that be a problem? Worse, it's a potential security hole because previously you'd get filtering and now you wouldn't. Considering that SCM_RIGHTS is usually used to transfer a file descriptor from a privileged process to an unprivileged one, I'd be very worried of that. Yeah, I know it's a security thing, was wondering how bad it was. So, if we choose this, I guess we'll need an ioctl to switch userland SG_IO filtering. What disturbs me is that it's a completely new interface to userland and at the same a very limited one at that. So, yeah, it's bothersome. I personally would prefer SCM_RIGHTS behavior change + hard coded filters per device class. I think hard-coded filters are bad (I prefer to move policy to userspace), and SCM_RIGHTS without a ioctl is out of question, really. No rule is really absolute. To me, it seems the suggested in-kernel per-device command code filter is both too big for the given problem while being too limited for much beyond that. So, if we can get away with adding an ioctl, I personally think that would be a better approach. 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/
[PATCH] acpi: add missing newline to printk
The missing newline causes messages like this on dmesg: [2.578212] ACPI: Invalid Power Resource to register!5[2.578456] ... Cc: Lin Ming ming.m@intel.com Cc: Len Brown len.br...@intel.com Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- drivers/acpi/power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 40e38a0..7db61b8 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -473,7 +473,7 @@ int acpi_power_resource_register_device(struct device *dev, acpi_handle handle) return ret; no_power_resource: - printk(KERN_DEBUG PREFIX Invalid Power Resource to register!); + printk(KERN_DEBUG PREFIX Invalid Power Resource to register!\n); return -ENODEV; } EXPORT_SYMBOL_GPL(acpi_power_resource_register_device); -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Fri, 2012-11-02 at 17:33 +0100, Pavel Machek wrote: On Thu 2012-11-01 15:02:25, Chris Friesen wrote: On 11/01/2012 02:27 PM, Pavel Machek wrote: Could someone write down exact requirements for Linux kernel to be signed by Microsoft? Because thats apparently what you want, and I don't think crippling kexec/suspend is enough. As I understand it, the kernel won't be signed by Microsoft. Rather, the bootloader will be signed by Microsoft and the vendors will be the ones that refuse to sign a kernel unless it is reasonably assured that it won't be used as an attack vector. Yes. So can someone write down what used as an attack vector means? Because, AFAICT, Linux kernel is _designed_ to work as an attact vector. We intentionally support wine, and want to keep that support. I think there's a variety of opinions on this one. My definition is that you can construct a signed boot system from the components delivered with a Linux distribution that will fairly invisibly chain load a hacked version of windows. Thus allowing the windows user to think they have a chain of trust to the UEFI firmware when, in fact, they haven't. The first question is how many compromises do you need. Without co-operation from windows, you don't get to install something in the boot system, so if you're looking for a single compromise vector, the only realistic attack is to trick the user into booting a hacked linux system from USB or DVD. There's also a lot of debate around fairly invisibly. If your hack involves shim-grub-linux-windows, that's a fairly long boot process with time for the user to notice something. Obviously, a boot loader that breaks the trust chain is ideal as a windows attack vector, which is why most pre bootloaders on virgin systems do a present user test (tell the user what they're doing and ask permission to continue). I really think that if the shim+MOK system always paused and asked to continue if the MOK Boot Services variables aren't present (i.e. it's a first boot virgin system), we've solved the windows attack vector problem, and we can move on from this rather sterile debate to think of how we can use secure boot to enhance Linux security for the machine owner. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 2/2] PCI/PM: Resume device before shutdown
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote: Some actions during shutdown need device to be in D0 state, such as MSI shutdown etc, so resume device before shutdown. Is there a problem report or bugzilla for this issue? What are the symptoms by which a user could figure out that he needs this fix? Should this be put in the stable tree as well? If so, for v3.6 only? Signed-off-by: Huang Ying ying.hu...@intel.com --- drivers/pci/pci-driver.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -398,6 +398,8 @@ static void pci_device_shutdown(struct d struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *drv = pci_dev-driver; + pm_runtime_resume(dev); + if (drv drv-shutdown) drv-shutdown(pci_dev); pci_msi_shutdown(pci_dev); @@ -408,16 +410,6 @@ static void pci_device_shutdown(struct d * continue to do DMA */ pci_disable_device(pci_dev); - - /* -* Devices may be enabled to wake up by runtime PM, but they need not -* be supposed to wake up the system from its power off state (e.g. -* ACPI S5). Therefore disable wakeup for all devices that aren't -* supposed to wake up the system at this point. The state argument -* will be ignored by pci_enable_wake(). -*/ - if (!device_may_wakeup(dev)) - pci_enable_wake(pci_dev, PCI_UNKNOWN, false); } #ifdef CONFIG_PM -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Second attempt at kernel secure boot support
On Fri, Nov 02, 2012 at 04:52:44PM +, James Bottomley wrote: The first question is how many compromises do you need. Without co-operation from windows, you don't get to install something in the boot system, so if you're looking for a single compromise vector, the only realistic attack is to trick the user into booting a hacked linux system from USB or DVD. You run a binary. It pops up a box saying Windows needs your permission to continue, just like almost every other Windows binary that's any use. Done. -- 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: [RFC] Second attempt at kernel secure boot support
On 11/02/2012 09:48 AM, Vivek Goyal wrote: On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Yep, good in theory. Now that basically means reimplementing kexec-tools in kernel. Maybe I'm missing something, but couldn't the vendors provide a signed kexec? Why does extra stuff need to be pushed into the kernel? Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] xen/hypercall: fix hypercall fallback code for very old hypervisors
On 02.11.12 at 17:44, Konrad Rzeszutek Wilk kon...@kernel.org wrote: --- a/arch/x86/include/asm/xen/hypercall.h +++ b/arch/x86/include/asm/xen/hypercall.h @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val, return _hypercall4(int, update_va_mapping, va, new_val.pte, new_val.pte 32, flags); } +extern int __must_check xen_HYPERVISOR_event_channel_op_compat(int, void *); Why don't you drop the HYPERVISOR_ now that you added the xen_? ... +EXPORT_SYMBOL_GPL(xen_HYPERVISOR_event_channel_op_compat); While this export is necessary, ... ... +EXPORT_SYMBOL_GPL(xen_HYPERVISOR_physdev_op_compat); ... I would recommend not adding this one without need. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: Kdump with signed images
On Thu, 2012-11-01 at 16:23 +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote: How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? There's ongoing work for providing mechanisms for trusting user keys. If you want Secure Boot turned on, you don't want any untrusted code running in your kernel. If you're happy with untrusted code in your kernel, why are you using Secure Boot? I would argue code written by a customer to run on their own systems is inherently trusted code and does not invalidate need/desire for Secure Boot. So the customer will still need some way to get their binary signed very painlessly just so they could use their own binary on their own system, simply because of a heavily locked down system design by Linux community. -- Khalid -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [ANNOUNCE] 3.6.5-rt14
[[ANNOUNCE] 3.6.5-rt14] On 01/11/2012 (Thu 21:57) Thomas Gleixner wrote: Dear RT Folks, I'm pleased to announce the 3.6.5-rt14 release. 3.6.4-rt12 is an intermediate release with a few changes. 3.6.5-rt13 is an update to 3.6.5 and 3.6.5-rt14 has a fix for my stupidity to release from the wrong tree missing a fix for x86-32. The rt14 content is available at the split queue repo on the master branch. I've also created a 3.6.5-rt14-fixes branch, which contains: 1) another %cx -- %ecx mismatch warning fix 2) fixes a bogus PREEMPT_LAZE in a select line 3) pointless newline removal fix carried over from 3.6.4-rt11-fixes All patches are fixed in-place directly within the existing patches without changing the series file (vs adding a separate patch for later folding). So they should be a drop in for integration even if folks aren't using this git repo to provide history tracking. Patches on the 3.6.5-rt14-fixes pass a basic boot test on x86_32 UP. For those who didn't catch one of the earlier posts[1] about the split patch queue repo, it is a history tracking repo of all the releases of the patches-3.6.X-rtY.tar.xz (X=gregkh stable, Y=rt version). Having the history repo allows you to track how each patch evolves, how the ordering changes and so on. You can use it just like a split queue tarball, in that you git am (or git quiltimport) the patches in the repo onto a gregkh stable tree, and then you can run git blame path/to/somefile to see seamless history across rt and back into stable/mainline as to who mangled what lines. The plus is, that rather than download and untar each time, you just go into where you've cloned this repo, and issue a git pull to get the latest update. Go to your kernel tree, checkout the appropriate gregkh stable baseline and reapply the patches and you are done. Folks can browse the repo at: http://git.kernel.org/?p=linux/kernel/git/paulg/3.6-rt-patches.git Paul. [1] http://permalink.gmane.org/gmane.linux.rt.user/8864 --- The following changes since commit 3f2b22edd602ef42f77abf345a0a777ccd4033ac: patches-3.6.5-rt14.tar.xz (2012-11-02 11:52:35 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/3.6-rt-patches.git v3.6.5-rt14-fixes for you to fetch changes up to a1221218459505df9a2d6c63d29432c637804a91: x86_32: fix %cx - %ecx mismatch on testl (2012-11-02 12:27:51 -0400) Paul Gortmaker (3): preempt-lazy-support.patch: delete trailing newline addition fix bogus HAVE_PREEMPT_LAZE in preempt-lazy-support.patch x86_32: fix %cx - %ecx mismatch on testl preempt-lazy-support.patch | 7 ++- x86-preempt-lazy.patch | 2 +- 2 files changed, 3 insertions(+), 6 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: [RFC] Second attempt at kernel secure boot support
On Fri, Nov 02, 2012 at 10:54:50AM -0600, Chris Friesen wrote: On 11/02/2012 09:48 AM, Vivek Goyal wrote: On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Yep, good in theory. Now that basically means reimplementing kexec-tools in kernel. Maybe I'm missing something, but couldn't the vendors provide a signed kexec? Why does extra stuff need to be pushed into the kernel? Bingo. Join us in following mail thread for all the gory details and extra work required to make signing of user space processes work. https://lkml.org/lkml/2012/10/24/451 In a nut-shell, there is no infrastructure currently for signing user space processes and verifying it (like module signing). Then if you just sign select user processes and not whole of the user space, then it brings extra complications with linking shared objects and being able to modify the code of process etc. So yes, being able to sign /sbin/kexec will be great. Looks like that itself will require lot of work and is not that straight forward. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen-blk: persistent-grants fixes
On Fri, Nov 02, 2012 at 04:43:04PM +0100, Roger Pau Monne wrote:
This patch contains fixes for persistent grants implementation v2:
* handle == 0 is a valid handle, so initialize grants in blkback
setting the handle to BLKBACK_INVALID_HANDLE instead of 0. Reported
by Konrad Rzeszutek Wilk.
* new_map is a boolean, use true or false instead of 1 and 0.
Reported by Konrad Rzeszutek Wilk.
* blkfront announces the persistent-grants feature as
feature-persistent-grants, use feature-persistent instead which is
consistent with blkback and the public Xen headers.
* Add a consistency check in blkfront to make sure we don't try to
access segments that have not been set.
Looks good.. but
Signed-off-by: Roger Pau Monne roger@citrix.com
Cc: konrad.w...@oracle.com
Cc: linux-kernel@vger.kernel.org
---
drivers/block/xen-blkback/blkback.c | 15 +--
drivers/block/xen-blkback/xenbus.c |2 +-
drivers/block/xen-blkfront.c|3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 663d42d..a059616 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -503,7 +503,7 @@ static int xen_blkbk_map(struct blkif_request *req,
* We are using persistent grants and
* the grant is already mapped
*/
- new_map = 0;
+ new_map = false;
} else if (use_persistent_gnts
blkif-persistent_gnt_c
max_mapped_grant_pages(blkif-blk_protocol)) {
@@ -511,8 +511,8 @@ static int xen_blkbk_map(struct blkif_request *req,
* We are using persistent grants, the grant is
* not mapped but we have room for it
*/
- new_map = 1;
- persistent_gnt = kzalloc(
+ new_map = true;
+ persistent_gnt = kmalloc(
Why do we want to use kmalloc instead of kzalloc?
sizeof(struct persistent_gnt),
GFP_KERNEL);
if (!persistent_gnt)
@@ -523,6 +523,7 @@ static int xen_blkbk_map(struct blkif_request *req,
return -ENOMEM;
}
persistent_gnt-gnt = req-u.rw.seg[i].gref;
+ persistent_gnt-handle = BLKBACK_INVALID_HANDLE;
pages_to_gnt[segs_to_map] =
persistent_gnt-page;
@@ -547,7 +548,7 @@ static int xen_blkbk_map(struct blkif_request *req,
pr_alert(DRV_PFX domain %u, device %#x is
using maximum number of persistent grants\n,
blkif-domid, blkif-vbd.handle);
}
- new_map = 1;
+ new_map = true;
pages[i] = blkbk-pending_page(pending_req, i);
addr = vaddr(pending_req, i);
pages_to_gnt[segs_to_map] =
@@ -584,7 +585,8 @@ static int xen_blkbk_map(struct blkif_request *req,
*/
bitmap_zero(pending_req-unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
for (i = 0, j = 0; i nseg; i++) {
- if (!persistent_gnts[i] || !persistent_gnts[i]-handle) {
+ if (!persistent_gnts[i] ||
+ persistent_gnts[i]-handle == BLKBACK_INVALID_HANDLE) {
/* This is a newly mapped grant */
BUG_ON(j = segs_to_map);
if (unlikely(map[j].status != 0)) {
@@ -601,7 +603,8 @@ static int xen_blkbk_map(struct blkif_request *req,
}
}
if (persistent_gnts[i]) {
- if (!persistent_gnts[i]-handle) {
+ if (persistent_gnts[i]-handle ==
+ BLKBACK_INVALID_HANDLE) {
/*
* If this is a new persistent grant
* save the handler
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index b225026..a03ecbb 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -760,7 +760,7 @@ static int connect_ring(struct backend_info *be)
return -1;
}
err = xenbus_gather(XBT_NIL, dev-otherend,
- feature-persistent-grants, %u,
+ feature-persistent, %u,
pers_grants, NULL);
if (err)
pers_grants = 0;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 911d733..f1de806 100644
--- a/drivers/block/xen-blkfront.c
[ 0/4] 3.0.51-stable review
This is the start of the stable review cycle for the 3.0.51 release. There are 4 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Nov 4 17:03:28 UTC 2012. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.51-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.0.51-rc1 Ben Skeggs bske...@redhat.com drm/nouveau: silence modesetting spam on pre-gf8 chipsets Jan Kara j...@suse.cz mm: fix XFS oops due to dirty pages without buffers on s390 Len Brown len.br...@intel.com x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility Herton Ronaldo Krzesinski herton.krzesin...@canonical.com floppy: do put_disk on current dr if blk_init_queue fails - Diffstat: Documentation/feature-removal-schedule.txt | 8 --- Makefile | 4 ++-- arch/x86/include/asm/system.h | 7 -- arch/x86/kernel/process.c | 24 --- drivers/block/floppy.c | 37 +- drivers/gpu/drm/nouveau/nv04_dac.c | 8 +++ drivers/gpu/drm/nouveau/nv04_dfp.c | 6 ++--- drivers/gpu/drm/nouveau/nv04_tv.c | 4 ++-- mm/rmap.c | 21 + 9 files changed, 28 insertions(+), 91 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/
[ 1/4] floppy: do put_disk on current dr if blk_init_queue fails
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.
If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).
Reviewed-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Jens Axboe ax...@kernel.dk
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/block/floppy.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4198,6 +4198,7 @@ static int __init floppy_init(void)
disks[dr]-queue = blk_init_queue(do_fd_request, floppy_lock);
if (!disks[dr]-queue) {
+ put_disk(disks[dr]);
err = -ENOMEM;
goto out_put_disk;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 3/4] mm: fix XFS oops due to dirty pages without buffers on s390
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara j...@suse.cz
commit ef5d437f71afdf4afdbab99213add99f4b1318fd upstream.
On s390 any write to a page (even from kernel itself) sets architecture
specific page dirty bit. Thus when a page is written to via buffered
write, HW dirty bit gets set and when we later map and unmap the page,
page_remove_rmap() finds the dirty bit and calls set_page_dirty().
Dirtying of a page which shouldn't be dirty can cause all sorts of
problems to filesystems. The bug we observed in practice is that
buffers from the page get freed, so when the page gets later marked as
dirty and writeback writes it, XFS crashes due to an assertion
BUG_ON(!PagePrivate(page)) in page_buffers() called from
xfs_count_page_state().
Similar problem can also happen when zero_user_segment() call from
xfs_vm_writepage() (or block_write_full_page() for that matter) set the
hardware dirty bit during writeback, later buffers get freed, and then
page unmapped.
Fix the issue by ignoring s390 HW dirty bit for page cache pages of
mappings with mapping_cap_account_dirty(). This is safe because for
such mappings when a page gets marked as writeable in PTE it is also
marked dirty in do_wp_page() or do_page_fault(). When the dirty bit is
cleared by clear_page_dirty_for_io(), the page gets writeprotected in
page_mkclean(). So pagecache page is writeable if and only if it is
dirty.
Thanks to Hugh Dickins for pointing out mapping has to have
mapping_cap_account_dirty() for things to work and proposing a cleaned
up variant of the patch.
The patch has survived about two hours of running fsx-linux on tmpfs
while heavily swapping and several days of running on out build machines
where the original problem was triggered.
Signed-off-by: Jan Kara j...@suse.cz
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Mel Gorman mgor...@suse.de
Cc: Hugh Dickins hu...@google.com
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
mm/rmap.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -57,6 +57,7 @@
#include linux/mmu_notifier.h
#include linux/migrate.h
#include linux/hugetlb.h
+#include linux/backing-dev.h
#include asm/tlbflush.h
@@ -936,11 +937,8 @@ int page_mkclean(struct page *page)
if (page_mapped(page)) {
struct address_space *mapping = page_mapping(page);
- if (mapping) {
+ if (mapping)
ret = page_mkclean_file(mapping, page);
- if (page_test_and_clear_dirty(page_to_pfn(page), 1))
- ret = 1;
- }
}
return ret;
@@ -1121,6 +1119,8 @@ void page_add_file_rmap(struct page *pag
*/
void page_remove_rmap(struct page *page)
{
+ struct address_space *mapping = page_mapping(page);
+
/* page still mapped by someone else? */
if (!atomic_add_negative(-1, page-_mapcount))
return;
@@ -1131,8 +1131,19 @@ void page_remove_rmap(struct page *page)
* this if the page is anon, so about to be freed; but perhaps
* not if it's in swapcache - there might be another pte slot
* containing the swap entry, but page not yet written to swap.
+*
+* And we can skip it on file pages, so long as the filesystem
+* participates in dirty tracking; but need to catch shm and tmpfs
+* and ramfs pages which have been modified since creation by read
+* fault.
+*
+* Note that mapping must be decided above, before decrementing
+* mapcount (which luckily provides a barrier): once page is unmapped,
+* it could be truncated and page-mapping reset to NULL at any moment.
+* Note also that we are relying on page_mapping(page) to set mapping
+* to swapper_space when PageSwapCache(page).
*/
- if ((!PageAnon(page) || PageSwapCache(page))
+ if (mapping !mapping_cap_account_dirty(mapping)
page_test_and_clear_dirty(page_to_pfn(page), 1))
set_page_dirty(page);
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 4/4] drm/nouveau: silence modesetting spam on pre-gf8 chipsets
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Skeggs bske...@redhat.com
commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/gpu/drm/nouveau/nv04_dac.c |8
drivers/gpu/drm/nouveau/nv04_dfp.c |6 +++---
drivers/gpu/drm/nouveau/nv04_tv.c |4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/nouveau/nv04_dac.c
+++ b/drivers/gpu/drm/nouveau/nv04_dac.c
@@ -209,7 +209,7 @@ out:
NVWriteVgaCrtc(dev, 0, NV_CIO_CR_MODE_INDEX, saved_cr_mode);
if (blue == 0x18) {
- NV_INFO(dev, Load detected on head A\n);
+ NV_DEBUG(dev, Load detected on head A\n);
return connector_status_connected;
}
@@ -323,7 +323,7 @@ nv17_dac_detect(struct drm_encoder *enco
if (nv17_dac_sample_load(encoder)
NV_PRAMDAC_TEST_CONTROL_SENSEB_ALLHI) {
- NV_INFO(dev, Load detected on output %c\n,
+ NV_DEBUG(dev, Load detected on output %c\n,
'@' + ffs(dcb-or));
return connector_status_connected;
} else {
@@ -398,7 +398,7 @@ static void nv04_dac_commit(struct drm_e
helper-dpms(encoder, DRM_MODE_DPMS_ON);
- NV_INFO(dev, Output %s is running on CRTC %d using output %c\n,
+ NV_DEBUG(dev, Output %s is running on CRTC %d using output %c\n,
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base),
nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
}
@@ -447,7 +447,7 @@ static void nv04_dac_dpms(struct drm_enc
return;
nv_encoder-last_dpms = mode;
- NV_INFO(dev, Setting dpms mode %d on vga encoder (output %d)\n,
+ NV_DEBUG(dev, Setting dpms mode %d on vga encoder (output %d)\n,
mode, nv_encoder-dcb-index);
nv04_dac_update_dacclk(encoder, mode == DRM_MODE_DPMS_ON);
--- a/drivers/gpu/drm/nouveau/nv04_dfp.c
+++ b/drivers/gpu/drm/nouveau/nv04_dfp.c
@@ -468,7 +468,7 @@ static void nv04_dfp_commit(struct drm_e
helper-dpms(encoder, DRM_MODE_DPMS_ON);
- NV_INFO(dev, Output %s is running on CRTC %d using output %c\n,
+ NV_DEBUG(dev, Output %s is running on CRTC %d using output %c\n,
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base),
nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
}
@@ -511,7 +511,7 @@ static void nv04_lvds_dpms(struct drm_en
return;
nv_encoder-last_dpms = mode;
- NV_INFO(dev, Setting dpms mode %d on lvds encoder (output %d)\n,
+ NV_DEBUG(dev, Setting dpms mode %d on lvds encoder (output %d)\n,
mode, nv_encoder-dcb-index);
if (was_powersaving is_powersaving_dpms(mode))
@@ -556,7 +556,7 @@ static void nv04_tmds_dpms(struct drm_en
return;
nv_encoder-last_dpms = mode;
- NV_INFO(dev, Setting dpms mode %d on tmds encoder (output %d)\n,
+ NV_DEBUG(dev, Setting dpms mode %d on tmds encoder (output %d)\n,
mode, nv_encoder-dcb-index);
nv04_dfp_update_backlight(encoder, mode);
--- a/drivers/gpu/drm/nouveau/nv04_tv.c
+++ b/drivers/gpu/drm/nouveau/nv04_tv.c
@@ -69,7 +69,7 @@ static void nv04_tv_dpms(struct drm_enco
struct nv04_mode_state *state = dev_priv-mode_reg;
uint8_t crtc1A;
- NV_INFO(dev, Setting dpms mode %d on TV encoder (output %d)\n,
+ NV_DEBUG(dev, Setting dpms mode %d on TV encoder (output %d)\n,
mode, nv_encoder-dcb-index);
state-pllsel = ~(PLLSEL_TV_CRTC1_MASK | PLLSEL_TV_CRTC2_MASK);
@@ -162,7 +162,7 @@ static void nv04_tv_commit(struct drm_en
helper-dpms(encoder, DRM_MODE_DPMS_ON);
- NV_INFO(dev, Output %s is running on CRTC %d using output %c\n,
+ NV_DEBUG(dev, Output %s is running on CRTC %d using output %c\n,
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base),
nv_crtc-index,
'@' + ffs(nv_encoder-dcb-or));
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 00/11] 3.4.18-stable review
This is the start of the stable review cycle for the 3.4.18 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Nov 4 17:03:08 UTC 2012. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.18-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.4.18-rc1 Ben Skeggs bske...@redhat.com drm/nouveau: headless mode by default if pci class != vga display Ben Skeggs bske...@redhat.com drm/nouveau: fix suspend/resume when in headless mode Ben Skeggs bske...@redhat.com drm/nouveau: silence modesetting spam on pre-gf8 chipsets Jiri Slaby jsl...@suse.cz HID: microsoft: fix invalid rdesc for 3k kbd Nicholas Bellinger n...@linux-iscsi.org target: Fix double-free of se_cmd in target_complete_tmr_failure Larry Finger larry.fin...@lwfinger.net b43: Fix oops on unload when firmware not found Herton Ronaldo Krzesinski herton.krzesin...@canonical.com floppy: do put_disk on current dr if blk_init_queue fails NeilBrown ne...@suse.de md/raid1: Fix assembling of arrays containing Replacements. Mathias Nyman mathias.ny...@linux.intel.com gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios Dan Carpenter dan.carpen...@oracle.com gpio-timberdale: fix a potential wrapping issue Eric Sandeen sand...@redhat.com ext4: fix unjournaled inode bitmap modification - Diffstat: Makefile| 4 ++-- drivers/block/floppy.c | 1 + drivers/gpio/gpio-timberdale.c | 4 ++-- drivers/gpio/gpiolib.c | 10 +++--- drivers/gpu/drm/nouveau/nouveau_drv.c | 20 +++- drivers/gpu/drm/nouveau/nouveau_state.c | 4 +++- drivers/gpu/drm/nouveau/nv04_dac.c | 8 drivers/gpu/drm/nouveau/nv04_dfp.c | 6 +++--- drivers/gpu/drm/nouveau/nv04_tv.c | 4 ++-- drivers/hid/hid-microsoft.c | 18 +- drivers/md/raid1.c | 2 +- drivers/net/wireless/b43/main.c | 2 ++ drivers/target/target_core_transport.c | 1 - fs/ext4/ialloc.c| 19 +-- 14 files changed, 60 insertions(+), 43 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/
[ 01/11] ext4: fix unjournaled inode bitmap modification
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Sandeen sand...@redhat.com
commit ffb5387e85d528fb6d0d924abfa3fbf0fc484071 upstream.
commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed
ext4_new_inode() such that the inode bitmap was being modified
outside a transaction, which could lead to corruption, and was
discovered when journal_checksum found a bad checksum in the
journal during log replay.
Nix ran into this when using the journal_async_commit mount
option, which enables journal checksumming. The ensuing
journal replay failures due to the bad checksums led to
filesystem corruption reported as the now infamous
Apparent serious progressive ext4 data corruption bug
[ Changed by tytso to only call ext4_journal_get_write_access() only
when we're fairly certain that we're going to allocate the inode. ]
I've tested this by mounting with journal_checksum and
running fsstress then dropping power; I've also tested by
hacking DM to create snapshots w/o first quiescing, which
allows me to test journal replay repeatedly w/o actually
power-cycling the box. Without the patch I hit a journal
checksum error every time. With this fix it survives
many iterations.
Reported-by: Nix n...@esperi.org.uk
Signed-off-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
fs/ext4/ialloc.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -697,6 +697,10 @@ repeat_in_this_group:
inode=%lu, ino + 1);
continue;
}
+ BUFFER_TRACE(inode_bitmap_bh, get_write_access);
+ err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
+ if (err)
+ goto fail;
ext4_lock_group(sb, group);
ret2 = ext4_test_and_set_bit(ino, inode_bitmap_bh-b_data);
ext4_unlock_group(sb, group);
@@ -710,6 +714,11 @@ repeat_in_this_group:
goto out;
got:
+ BUFFER_TRACE(inode_bitmap_bh, call ext4_handle_dirty_metadata);
+ err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
+ if (err)
+ goto fail;
+
/* We may have to initialize the block bitmap if it isn't already */
if (EXT4_HAS_RO_COMPAT_FEATURE(sb, EXT4_FEATURE_RO_COMPAT_GDT_CSUM)
gdp-bg_flags cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
@@ -742,11 +751,6 @@ got:
goto fail;
}
- BUFFER_TRACE(inode_bitmap_bh, get_write_access);
- err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
- if (err)
- goto fail;
-
BUFFER_TRACE(group_desc_bh, get_write_access);
err = ext4_journal_get_write_access(handle, group_desc_bh);
if (err)
@@ -789,11 +793,6 @@ got:
ext4_unlock_group(sb, group);
}
- BUFFER_TRACE(inode_bitmap_bh, call ext4_handle_dirty_metadata);
- err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
- if (err)
- goto fail;
-
BUFFER_TRACE(group_desc_bh, call ext4_handle_dirty_metadata);
err = ext4_handle_dirty_metadata(handle, NULL, group_desc_bh);
if (err)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 03/11] gpiolib: Dont return -EPROBE_DEFER to sysfs, or for invalid gpios
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mathias Nyman mathias.ny...@linux.intel.com
commit ad2fab36d7922401c4576fb7ea9b21a47a29a17f upstream.
gpios requested with invalid numbers, or gpios requested from userspace via
sysfs
should not try to be deferred on failure.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/gpio/gpiolib.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -623,9 +623,11 @@ static ssize_t export_store(struct class
*/
status = gpio_request(gpio, sysfs);
- if (status 0)
+ if (status 0) {
+ if (status == -EPROBE_DEFER)
+ status = -ENODEV;
goto done;
-
+ }
status = gpio_export(gpio, true);
if (status 0)
gpio_free(gpio);
@@ -1191,8 +1193,10 @@ int gpio_request(unsigned gpio, const ch
spin_lock_irqsave(gpio_lock, flags);
- if (!gpio_is_valid(gpio))
+ if (!gpio_is_valid(gpio)) {
+ status = -EINVAL;
goto done;
+ }
desc = gpio_desc[gpio];
chip = desc-chip;
if (chip == NULL)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 17/24] USB: io_edgeport: remove unused variable
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Bolle pebo...@tiscali.nl
The stable commit 12ddc74e8e25107eda81aceb74e3311c1480b381
(USB: io_edgeport: fix port-data memory leak) left one variable
unused:
drivers/usb/serial/io_edgeport.c: In function 'edge_release':
drivers/usb/serial/io_edgeport.c:3155:6: warning: unused variable 'i'
[-Wunused-variable]
Remove this unused variable.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/serial/io_edgeport.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -3152,7 +3152,6 @@ static void edge_disconnect(struct usb_s
static void edge_release(struct usb_serial *serial)
{
struct edgeport_serial *edge_serial = usb_get_serial_data(serial);
- int i;
dbg(%s, __func__);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 23/24] drm/nouveau: fix suspend/resume when in headless mode
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Skeggs bske...@redhat.com
Backport of fixes from upstream commit:
9430738d80223a1cd791a2baa74fa170d3df1262
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/gpu/drm/nouveau/nouveau_drv.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -188,11 +188,13 @@ nouveau_pci_suspend(struct pci_dev *pdev
if (dev-switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- NV_INFO(dev, Disabling display...\n);
- nouveau_display_fini(dev);
+ if (dev-mode_config.num_crtc) {
+ NV_INFO(dev, Disabling display...\n);
+ nouveau_display_fini(dev);
- NV_INFO(dev, Disabling fbcon...\n);
- nouveau_fbcon_set_suspend(dev, 1);
+ NV_INFO(dev, Disabling fbcon...\n);
+ nouveau_fbcon_set_suspend(dev, 1);
+ }
NV_INFO(dev, Unpinning framebuffer(s)...\n);
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
@@ -359,10 +361,12 @@ nouveau_pci_resume(struct pci_dev *pdev)
NV_ERROR(dev, Could not pin/map cursor.\n);
}
- nouveau_fbcon_set_suspend(dev, 0);
- nouveau_fbcon_zfill_all(dev);
+ if (dev-mode_config.num_crtc) {
+ nouveau_fbcon_set_suspend(dev, 0);
+ nouveau_fbcon_zfill_all(dev);
- nouveau_display_init(dev);
+ nouveau_display_init(dev);
+ }
/* Force CLUT to get re-loaded during modeset */
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 24/24] drm/nouveau: headless mode by default if pci class != vga display
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Skeggs bske...@redhat.com
This is to prevent nouveau from taking over the console on headless boards
such as Tesla.
Backport of upstream commit: e412e95a268fa8544858ebfe066826b290430d51
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/gpu/drm/nouveau/nouveau_drv.c |2 --
drivers/gpu/drm/nouveau/nouveau_state.c |4 +++-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -488,9 +488,7 @@ static int __init nouveau_init(void)
#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force())
nouveau_modeset = 0;
- else
#endif
- nouveau_modeset = 1;
}
if (!nouveau_modeset)
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -50,6 +50,7 @@ static int nouveau_init_engine_ptrs(stru
{
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_engine *engine = dev_priv-engine;
+ u32 pclass = dev-pdev-class 8;
switch (dev_priv-chipset 0xf0) {
case 0x00:
@@ -428,7 +429,8 @@ static int nouveau_init_engine_ptrs(stru
}
/* headless mode */
- if (nouveau_modeset == 2) {
+ if (nouveau_modeset == 2 ||
+ (nouveau_modeset 0 pclass != PCI_CLASS_DISPLAY_VGA)) {
engine-display.early_init = nouveau_stub_init;
engine-display.late_takedown = nouveau_stub_takedown;
engine-display.create = nouveau_stub_init;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 15/24] USB: mos7840: fix port-data memory leak
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold jhov...@gmail.com
commit 80c00750f0c9867a65b30a17880939b6bc660a77 upstream.
Fix port-data memory leak by moving port data allocation and
deallocation to port_probe and port_remove.
Since commit 0998d0631001288 (device-core: Ensure drvdata = NULL when no
driver is bound) the port private data is no longer freed at release as
it is no longer accessible.
Note that the indentation was kept intact using a do-while(0) in order
to facilitate review. A follow-up patch will remove it.
Compile-only tested.
Signed-off-by: Johan Hovold jhov...@gmail.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
This a backport of 80c00750f0c9867 from v3.7-rc to v3.6.5 as requested.
Thanks,
Johan
drivers/usb/serial/mos7840.c | 198 +++
1 file changed, 71 insertions(+), 127 deletions(-)
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -2405,52 +2405,43 @@ static int mos7840_calc_num_ports(struct
return mos7840_num_ports;
}
-/
- * mos7840_startup
- /
-
-static int mos7840_startup(struct usb_serial *serial)
+static int mos7840_port_probe(struct usb_serial_port *port)
{
+ struct usb_serial *serial = port-serial;
struct moschip_port *mos7840_port;
- struct usb_device *dev;
- int i, status;
+ int status;
+ int pnum;
__u16 Data;
- if (!serial) {
- dbg(%s, Invalid Handler);
- return -1;
- }
-
- dev = serial-dev;
-
/* we set up the pointers to the endpoints in the mos7840_open *
* function, as the structures aren't created yet. */
- /* set up port private structures */
- for (i = 0; i serial-num_ports; ++i) {
- dbg (mos7840_startup: configuring port %d, i);
+ pnum = port-number - serial-minor;
+
+ /* FIXME: remove do-while(0) loop used to keep stable patch minimal.
+*/
+ do {
+ dbg(mos7840_startup: configuring port %d, pnum);
mos7840_port = kzalloc(sizeof(struct moschip_port), GFP_KERNEL);
if (mos7840_port == NULL) {
- dev_err(dev-dev, %s - Out of memory\n, __func__);
- status = -ENOMEM;
- i--; /* don't follow NULL pointer cleaning up */
- goto error;
+ dev_err(port-dev, %s - Out of memory\n, __func__);
+ return -ENOMEM;
}
/* Initialize all port interrupt end point to port 0 int
* endpoint. Our device has only one interrupt end point
* common to all port */
- mos7840_port-port = serial-port[i];
- mos7840_set_port_private(serial-port[i], mos7840_port);
+ mos7840_port-port = port;
+ mos7840_set_port_private(port, mos7840_port);
spin_lock_init(mos7840_port-pool_lock);
/* minor is not initialised until later by
* usb-serial.c:get_free_serial() and cannot therefore be used
* to index device instances */
- mos7840_port-port_num = i + 1;
- dbg (serial-port[i]-number = %d, serial-port[i]-number);
- dbg (serial-port[i]-serial-minor = %d,
serial-port[i]-serial-minor);
+ mos7840_port-port_num = pnum + 1;
+ dbg(port-number = %d, port-number);
+ dbg(port-serial-minor = %d, port-serial-minor);
dbg (mos7840_port-port_num = %d, mos7840_port-port_num);
dbg (serial-minor = %d, serial-minor);
@@ -2480,10 +2471,10 @@ static int mos7840_startup(struct usb_se
mos7840_port-DcrRegOffset = 0x1c;
}
mos7840_dump_serial_port(mos7840_port);
- mos7840_set_port_private(serial-port[i], mos7840_port);
+ mos7840_set_port_private(port, mos7840_port);
/* enable rx_disable bit in control register */
- status = mos7840_get_reg_sync(serial-port[i],
+ status = mos7840_get_reg_sync(port,
mos7840_port-ControlRegOffset, Data);
if (status 0) {
dbg(Reading ControlReg failed status-0x%x, status);
@@ -2491,12 +2482,13 @@ static int mos7840_startup(struct usb_se
} else
dbg(ControlReg Reading success val is %x, status%d,
Data, status);
+
Data |= 0x08; /* setting driver done bit */
Data |= 0x04; /* sp1_bit to have cts change reflect in
[ 07/24] floppy: do put_disk on current dr if blk_init_queue fails
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.
If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).
Reviewed-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Jens Axboe ax...@kernel.dk
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/block/floppy.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4151,6 +4151,7 @@ static int __init do_floppy_init(void)
disks[dr]-queue = blk_init_queue(do_fd_request, floppy_lock);
if (!disks[dr]-queue) {
+ put_disk(disks[dr]);
err = -ENOMEM;
goto out_put_disk;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
