Regression: drm/nouveau/clk: implement power state and engine clock control in core (7c856522069755ab9d163a24ac332cd3cb35fe30) breaks GeForce 9400 on Intel Mac Mini Model November 2010 model
Hello everyone, the current git HEAD of Linus Torvalds tree breaks Nouveau on my Mac Mini Model 2010. I get variation of the following kernel panic when booting. (gateway) [~] nc -u -l -p [3.796018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [3.796100] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [3.796304] ata1.00: ATA-7: INTEL SSDSA2M160G2GC, 2CV102HA, max UDMA/133 [3.796370] ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32) [3.796672] ata1.00: configured for UDMA/133 [3.796894] scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2M160 2CV1 PQ: 0 ANSI: 5 [3.806643] ata2.00: ATAPI: PIONEER DVD-RW DVRTS08, Q81B, max UDMA/33 [3.818934] ata2.00: configured for UDMA/33 [3.873892] scsi 1:0:0:0: CD-ROMPIONEER DVD-RW DVRTS08 Q81B PQ: 0 ANSI: 5 [3.884561] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB) [3.884790] sd 0:0:0:0: [sda] Write Protect is off [3.884898] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.885526] sda: sda1 [3.885973] sd 0:0:0:0: [sda] Attached SCSI disk [3.920096] firewire_core :04:00.0: created device fw0: GUID 0023de7ed446, S800 [3.934618] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda caddy [3.934684] cdrom: Uniform CD-ROM driver Revision: 3.20 [3.938525] sd 0:0:0:0: Attached scsi generic sg0 type 0 [3.938659] sr 1:0:0:0: Attached scsi generic sg1 type 5 [4.248270] device-mapper: uevent: version 1.0.3 [4.248427] device-mapper: ioctl: 4.26.0-ioctl (2013-08-15) initialised: dm-de...@redhat.com [4.324025] raid6: sse2x12845 MB/s [4.392010] raid6: sse2x23597 MB/s [4.460007] raid6: sse2x44706 MB/s [4.460068] raid6: using algorithm sse2x4 (4706 MB/s) [4.460136] raid6: using ssse3x2 recovery algorithm [4.460405] xor: measuring software checksum speed [4.54]prefetch64-sse: 6964.000 MB/sec [4.540003]generic_sse: 6115.000 MB/sec [4.540065] xor: using function: prefetch64-sse (6964.000 MB/sec) [4.548866] bio: create slab at 1 [4.549122] Btrfs loaded [4.690419] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [4.945318] udevd[440]: starting version 175 [5.025560] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 [5.025648] ACPI: Power Button [PWRB] [5.025789] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input1 [5.025792] ACPI: Sleep Button [SLPB] [5.025922] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [5.025924] ACPI: Power Button [PWRF] [5.026903] ACPI: Requesting acpi_cpufreq [5.031899] tsc: Marking TSC unstable due to TSC halts in idle [5.034066] Switched to clocksource hpet [5.123175] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [5.123579] input: PC Speaker as /devices/platform/pcspkr/input/input3 [5.124160] i2c i2c-0: nForce2 SMBus adapter at 0x2140 [5.124260] i2c i2c-1: nForce2 SMBus adapter at 0x2100 [5.125485] ACPI: bus type USB registered [5.125577] usbcore: registered new interface driver usbfs [5.125650] usbcore: registered new interface driver hub [5.127100] usbcore: registered new device driver usb [5.128156] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [5.129481] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [5.130620] ohci-pci: OHCI PCI platform driver [5.130902] ohci-pci :00:04.0: OHCI PCI host controller [5.130972] ohci-pci :00:04.0: new USB bus registered, assigned bus number 1 [5.131077] ohci-pci :00:04.0: irq 23, io mem 0xd3488000 [5.131288] ehci-pci: EHCI PCI platform driver [5.173695] ssb: Found chip with id 0x4321, rev 0x05 and package 0x00 [5.187724] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [5.187797] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [5.187878] usb usb1: Product: OHCI PCI host controller [5.187938] usb usb1: Manufacturer: Linux 3.12.0-rc3+ ohci_hcd [5.188020] usb usb1: SerialNumber: :00:04.0 [5.188459] hub 1-0:1.0: USB hub found [5.188564] hub 1-0:1.0: 7 ports detected [5.189220] ehci-pci :00:04.1: EHCI Host Controller [5.189284] ehci-pci :00:04.1: new USB bus registered, assigned bus number 2 [5.189363] ehci-pci :00:04.1: debug port 1 [5.189463] ehci-pci :00:04.1: irq 22, io mem 0xd3489200 [5.202613] ehci-pci :00:04.1: USB 2.0 started, EHCI 1.00 [5.203875] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [5.203940] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [5.204036] usb usb2: Product: EHCI Host Controller [5.204100] usb usb2: Manufacturer: Linux 3.12.0-rc3+ ehci_hcd [5.204163] usb usb2: SerialNumber: :00:04.1 [5.204417] hub
RE: [PATCH 3/3 v5] usb: chipidea: put hw_phymode_configure before ci_usb_phy_init
>
> usb: chipidea: put hw_phymode_configure before ci_usb_phy_init
>
> hw_phymode_configure configures the PORTSC registers and allow the
> following phy_inits to operate on the right parameters. This fix a
> problem
> where the UPLI (ISP1504) could not be detected, because the Viewport was
> not
> available and read the viewport return 0's only.
>
> Signed-off-by: Chris Ruehl
> Acked-by: Peter Chen
> ---
> drivers/usb/chipidea/core.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 2834801..43897dd 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -564,6 +564,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + hw_phymode_configure(ci);
> +
> ret = ci_usb_phy_init(ci);
> if (ret) {
> dev_err(dev, "unable to init phy: %d\n", ret);
> @@ -581,8 +583,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>
> ci_get_otg_capable(ci);
>
> - hw_phymode_configure(ci);
> -
> dr_mode = ci->platdata->dr_mode;
> /* initialize role(s) before the interrupt is requested */
> if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
> --
> 1.7.10.4
>
Applied, Thanks.
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: TIDSPBRIDGE: Remove UUID helper
My other patch (the one that fixes the security issue) was already applied, albeit it was sent after this one, see https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-linus=559c71fe5dc3bf2ecc55afb336145db7f0abf810 , that is why I think there is some problem with the mail itself. Sure I will wait :) regards, Ivo On 06.12.2013 09:32, Dan Carpenter wrote: On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: Hi Greg, On 01.12.2013 19:07, Ivaylo DImitrov wrote: From: Ivaylo Dimitrov Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't need to be exported. It can also be made way simpler by using sscanf. Signed-off-by: Ivaylo Dimitrov --- drivers/staging/tidspbridge/Makefile |2 +- drivers/staging/tidspbridge/gen/uuidutil.c | 85 .../tidspbridge/include/dspbridge/uuidutil.h | 18 drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- 4 files changed, 39 insertions(+), 108 deletions(-) delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c I guess the initial mail somehow didn't make it through your spam filter: https://lkml.org/lkml/2013/12/1/70 It's too early to start resending. Wait for another week at least. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 v5] Fix Internal error: : 808 [#1] ARM related to STS flag
On Wed, Dec 04, 2013 at 09:56:18AM +0800, Chris Ruehl wrote:
> Fix Internal error: : 808 [#1] ARM related to STS flag
>
> * init the sts flag to 0 (missed)
> * fix write the real bit not sts value
> * Set PORTCS_STS and DEVLC_STS only if sts = 1
> (prefered solution by Mr. Peter Chen, Maintainer of ChipIdea subsystem)
>
> Signed-off-by: Chris Ruehl
> ---
> drivers/usb/chipidea/core.c |8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 9a5ef20..2834801 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -243,7 +243,7 @@ static int hw_device_init(struct ci_hdrc *ci, void
> __iomem *base)
>
> static void hw_phymode_configure(struct ci_hdrc *ci)
> {
> - u32 portsc, lpm, sts;
> + u32 portsc, lpm, sts = 0;
>
> switch (ci->platdata->phy_mode) {
> case USBPHY_INTERFACE_MODE_UTMI:
> @@ -273,10 +273,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
>
> if (ci->hw_bank.lpm) {
> hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
> - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
> + if (sts)
> + hw_write(ci, OP_DEVLC, DEVLC_STS, DEVLC_STS);
> } else {
> hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
> - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
> + if (sts)
> + hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
> }
> }
>
> --
> 1.7.10.4
>
>
Applied, Thanks.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/Processor: use ACPI_COMPANION to get ACPI device
Using ACPI_COMPANION to get ACPI device instead of acpi_bus_get_device().
Signed-off-by: Lan Tianyu
---
drivers/acpi/processor_driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 146ab7e..c1c3562 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -224,9 +224,9 @@ static int __acpi_processor_start(struct acpi_device
*device)
static int acpi_processor_start(struct device *dev)
{
- struct acpi_device *device;
+ struct acpi_device *device = ACPI_COMPANION(dev);
- if (acpi_bus_get_device(ACPI_HANDLE(dev), ))
+ if (!device)
return -ENODEV;
return __acpi_processor_start(device);
@@ -234,10 +234,10 @@ static int acpi_processor_start(struct device *dev)
static int acpi_processor_stop(struct device *dev)
{
- struct acpi_device *device;
+ struct acpi_device *device = ACPI_COMPANION(dev);
struct acpi_processor *pr;
- if (acpi_bus_get_device(ACPI_HANDLE(dev), ))
+ if (!device)
return 0;
acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
--
1.8.2.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] Staging: TIDSPBRIDGE: Remove UUID helper
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote: > Hi Greg, > > On 01.12.2013 19:07, Ivaylo DImitrov wrote: > >From: Ivaylo Dimitrov > > > >Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't > >need to be exported. It can also be made way simpler by using sscanf. > > > >Signed-off-by: Ivaylo Dimitrov > >--- > > drivers/staging/tidspbridge/Makefile |2 +- > > drivers/staging/tidspbridge/gen/uuidutil.c | 85 > > > > .../tidspbridge/include/dspbridge/uuidutil.h | 18 > > drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- > > 4 files changed, 39 insertions(+), 108 deletions(-) > > delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c > > > > I guess the initial mail somehow didn't make it through your spam filter: > https://lkml.org/lkml/2013/12/1/70 > It's too early to start resending. Wait for another week at least. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] perf script: Improve srcline display for BTS
Change the order of the output to put the srcline last.
e.g. old format:
4028fc main+0x2c (/bin/ls)
/build/buildd/coreutils-8.20/src/ls.c:1269 => 40d8a0
set_program_name+0x0 (/bin/ls)
new format:
4028fc main+0x2c (/bin/ls) => 40d8a0 set_program_name+0x0
(/bin/ls)
/build/buildd/coreutils-8.20/src/ls.c:1269
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-script.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 7a571fb..8997b69 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -428,15 +428,22 @@ static void print_sample_bts(union perf_event *event,
struct addr_location *al)
{
struct perf_event_attr *attr = >attr;
+ bool print_srcline_last = false;
/* print branch_from information */
if (PRINT_FIELD(IP)) {
- if (!symbol_conf.use_callchain)
- printf(" ");
- else
+ unsigned int print_opts = output[attr->type].print_ip_opts;
+
+ if (symbol_conf.use_callchain && sample->callchain) {
printf("\n");
- perf_evsel__print_ip(evsel, sample, machine, al,
-output[attr->type].print_ip_opts,
+ } else {
+ printf(" ");
+ if (print_opts & PRINT_IP_OPT_SRCLINE) {
+ print_srcline_last = true;
+ print_opts &= ~PRINT_IP_OPT_SRCLINE;
+ }
+ }
+ perf_evsel__print_ip(evsel, sample, machine, al, print_opts,
PERF_MAX_STACK_DEPTH);
}
@@ -448,6 +455,9 @@ static void print_sample_bts(union perf_event *event,
!output[attr->type].user_set))
print_sample_addr(event, sample, machine, thread, attr);
+ if (print_srcline_last)
+ map__fprintf_srcline(al->map, al->addr, "\n ", stdout);
+
printf("\n");
}
--
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 V2] arm: mmp: build sram driver alone
On Thu, Dec 5, 2013 at 10:00 AM, Dan Williams wrote: > On Wed, Dec 4, 2013 at 5:36 PM, Qiao Zhou wrote: >> sram driver can be used by many chips besides CPU_MMP2, and so build >> it alone. Also need to select MMP_SRAM for MMP_TDMA driver. >> >> Reported-by: Dan Williams >> Signed-off-by: Qiao Zhou >> --- > > Looks good, thanks for fixing it up. > > -- > Dan Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] perf script: Add an option to print the source line number
Add field 'srcline' that displays the source file name
and line number associated with the sample ip. The
information displayed is the same as from addr2line.
Signed-off-by: Adrian Hunter
---
tools/perf/Documentation/perf-script.txt | 2 +-
tools/perf/builtin-script.c | 10 ++
tools/perf/util/map.c| 17 +
tools/perf/util/map.h| 2 ++
tools/perf/util/session.c| 8
tools/perf/util/session.h| 1 +
6 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index cfdbb1e..c2a5071 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -115,7 +115,7 @@ OPTIONS
-f::
--fields::
Comma separated list of fields to print. Options are:
-comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff.
+comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
srcline.
Field list can be prepended with the type, trace, sw or hw,
to indicate to which event type the field list applies.
e.g., -f sw:comm,tid,time,ip,sym and -f trace:time,cpu,trace
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 4484886..7a571fb 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -43,6 +43,7 @@ enum perf_output_field {
PERF_OUTPUT_DSO = 1U << 9,
PERF_OUTPUT_ADDR= 1U << 10,
PERF_OUTPUT_SYMOFFSET = 1U << 11,
+ PERF_OUTPUT_SRCLINE = 1U << 12,
};
struct output_option {
@@ -61,6 +62,7 @@ struct output_option {
{.str = "dso", .field = PERF_OUTPUT_DSO},
{.str = "addr", .field = PERF_OUTPUT_ADDR},
{.str = "symoff", .field = PERF_OUTPUT_SYMOFFSET},
+ {.str = "srcline", .field = PERF_OUTPUT_SRCLINE},
};
/* default set to maintain compatibility with current format */
@@ -210,6 +212,11 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
"to DSO.\n");
return -EINVAL;
}
+ if (PRINT_FIELD(SRCLINE) && !PRINT_FIELD(IP)) {
+ pr_err("Display of source line number requested but sample IP
is not\n"
+ "selected. Hence, no address to lookup the source line
number.\n");
+ return -EINVAL;
+ }
if ((PRINT_FIELD(PID) || PRINT_FIELD(TID)) &&
perf_evsel__check_stype(evsel, PERF_SAMPLE_TID, "TID",
@@ -245,6 +252,9 @@ static void set_print_ip_opts(struct perf_event_attr *attr)
if (PRINT_FIELD(SYMOFFSET))
output[type].print_ip_opts |= PRINT_IP_OPT_SYMOFFSET;
+
+ if (PRINT_FIELD(SRCLINE))
+ output[type].print_ip_opts |= PRINT_IP_OPT_SRCLINE;
}
/*
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index ef5bc91..9b9bd71 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -11,6 +11,7 @@
#include "strlist.h"
#include "vdso.h"
#include "build-id.h"
+#include "util.h"
#include
const char *map_type__name[MAP__NR_TYPES] = {
@@ -252,6 +253,22 @@ size_t map__fprintf_dsoname(struct map *map, FILE *fp)
return fprintf(fp, "%s", dsoname);
}
+int map__fprintf_srcline(struct map *map, u64 addr, const char *prefix,
+FILE *fp)
+{
+ char *srcline;
+ int ret = 0;
+
+ if (map && map->dso) {
+ srcline = get_srcline(map->dso,
+ map__rip_2objdump(map, addr));
+ if (srcline != SRCLINE_UNKNOWN)
+ ret = fprintf(fp, "%s%s", prefix, srcline);
+ free_srcline(srcline);
+ }
+ return ret;
+}
+
/**
* map__rip_2objdump - convert symbol start address to objdump address.
* @map: memory map
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index e4e259c..18068c6 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -103,6 +103,8 @@ struct map *map__clone(struct map *map);
int map__overlap(struct map *l, struct map *r);
size_t map__fprintf(struct map *map, FILE *fp);
size_t map__fprintf_dsoname(struct map *map, FILE *fp);
+int map__fprintf_srcline(struct map *map, u64 addr, const char *prefix,
+FILE *fp);
int map__load(struct map *map, symbol_filter_t filter);
struct symbol *map__find_symbol(struct map *map,
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index c236b38..e748f29 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1497,6 +1497,7 @@ void perf_evsel__print_ip(struct perf_evsel *evsel,
struct perf_sample *sample,
int print_dso = print_opts & PRINT_IP_OPT_DSO;
int print_symoffset = print_opts & PRINT_IP_OPT_SYMOFFSET;
int print_oneline = print_opts & PRINT_IP_OPT_ONELINE;
+ int print_srcline =
[PATCH V2 1/3] perf script: Fix symoff printing in callchains
The address being used to calculate the offset was
the memory address but the address needed is the
address mapped to the dso. i.e. the 'addr' member
of 'struct addr_location'
Signed-off-by: Adrian Hunter
---
tools/perf/util/session.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 8a7da6f..c236b38 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1515,6 +1515,8 @@ void perf_evsel__print_ip(struct perf_evsel *evsel,
struct perf_sample *sample,
node_al = *al;
while (stack_depth) {
+ u64 addr = 0;
+
node = callchain_cursor_current(_cursor);
if (!node)
break;
@@ -1525,10 +1527,13 @@ void perf_evsel__print_ip(struct perf_evsel *evsel,
struct perf_sample *sample,
if (print_ip)
printf("%c%16" PRIx64, s, node->ip);
+ if (node->map)
+ addr = node->map->map_ip(node->map, node->ip);
+
if (print_sym) {
printf(" ");
if (print_symoffset) {
- node_al.addr = node->ip;
+ node_al.addr = addr;
node_al.map = node->map;
symbol__fprintf_symname_offs(node->sym,
_al, stdout);
} else
--
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 V2 0/3] perf script: Add an option to print the source line number
Hi Here is perf script srcline printing. Changes in V2: Also print scrline for callchains Adrian Hunter (3): perf script: Fix symoff printing in callchains perf script: Add an option to print the source line number perf script: Improve srcline display for BTS tools/perf/Documentation/perf-script.txt | 2 +- tools/perf/builtin-script.c | 30 +- tools/perf/util/map.c| 17 + tools/perf/util/map.h| 2 ++ tools/perf/util/session.c| 15 ++- tools/perf/util/session.h| 1 + 6 files changed, 60 insertions(+), 7 deletions(-) Regards Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: chipidea: fix device tree binding for zevio/nspire usb driver
On Thu, Dec 05, 2013 at 05:37:01PM +1100, dt.ta...@gmail.com wrote:
> From: Daniel Tang
>
> The device tree binding chosen for the nspire-usb driver was inappropriate and
> should be renamed to lsi,zevio-usb.
>
> References to nspire have been replaced with zevio (the SoC name)
>
> Signed-off-by: Daniel Tang
> ---
> .../devicetree/bindings/usb/ci-hdrc-nspire.txt | 17 -
> .../devicetree/bindings/usb/ci-hdrc-zevio.txt | 17 +
> drivers/usb/chipidea/Makefile |2 +-
> drivers/usb/chipidea/ci_hdrc_nspire.c | 72
>
> drivers/usb/chipidea/ci_hdrc_zevio.c | 72
>
> 5 files changed, 90 insertions(+), 90 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
> create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
> delete mode 100644 drivers/usb/chipidea/ci_hdrc_nspire.c
> create mode 100644 drivers/usb/chipidea/ci_hdrc_zevio.c
>
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
> b/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
> deleted file mode 100644
> index ef1fcbf..000
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -* TI-Nspire USB OTG Controller
> -
> -Required properties:
> -- compatible: Should be "lsi,nspire-usb"
> -- reg: Should contain registers location and length
> -- interrupts: Should contain controller interrupt
> -
> -Recommended properies:
> -- vbus-supply: regulator for vbus
> -
> -Examples:
> - usb0: usb@B000 {
> - reg = <0xB000 0x1000>;
> - compatible = "lsi,nspire-usb";
> - interrupts = <8>;
> - vbus-supply = <_reg>;
> - };
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
> b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
> new file mode 100644
> index 000..b6c3b5c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
> @@ -0,0 +1,17 @@
> +* TI-Nspire USB OTG Controller
> +
TI-Nspire is a platform which uses zevio SoC, correct?
So, please do not use TI-Nspire above.
Peter
> +Required properties:
> +- compatible: Should be "lsi,zevio-usb"
> +- reg: Should contain registers location and length
> +- interrupts: Should contain controller interrupt
> +
> +Recommended properies:
> +- vbus-supply: regulator for vbus
> +
> +Examples:
> + usb0: usb@B000 {
> + reg = <0xB000 0x1000>;
> + compatible = "lsi,zevio-usb";
> + interrupts = <8>;
> + vbus-supply = <_reg>;
> + };
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 245ea4d..7635407 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -10,7 +10,7 @@ ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)+= debug.o
> # Glue/Bridge layers go here
>
> obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
> -obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_nspire.o
> +obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
>
> # PCI doesn't provide stubs, need to check
> ifneq ($(CONFIG_PCI),)
> diff --git a/drivers/usb/chipidea/ci_hdrc_nspire.c
> b/drivers/usb/chipidea/ci_hdrc_nspire.c
> deleted file mode 100644
> index c5c2dde..000
> --- a/drivers/usb/chipidea/ci_hdrc_nspire.c
> +++ /dev/null
> @@ -1,72 +0,0 @@
> -/*
> - * Copyright (C) 2013 Daniel Tang
> - *
> - * 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.
> - *
> - * Based off drivers/usb/chipidea/ci_hdrc_msm.c
> - *
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -
> -#include "ci.h"
> -
> -static struct ci_hdrc_platform_data ci_hdrc_nspire_platdata = {
> - .name = "ci_hdrc_nspire",
> - .flags = CI_HDRC_REGS_SHARED,
> - .capoffset = DEF_CAPOFFSET,
> -};
> -
> -static int ci_hdrc_nspire_probe(struct platform_device *pdev)
> -{
> - struct platform_device *ci_pdev;
> -
> - dev_dbg(>dev, "ci_hdrc_nspire_probe\n");
> -
> - ci_pdev = ci_hdrc_add_device(>dev,
> - pdev->resource, pdev->num_resources,
> - _hdrc_nspire_platdata);
> -
> - if (IS_ERR(ci_pdev)) {
> - dev_err(>dev, "ci_hdrc_add_device failed!\n");
> - return PTR_ERR(ci_pdev);
> - }
> -
> - platform_set_drvdata(pdev, ci_pdev);
> -
> - return 0;
> -}
> -
> -static int ci_hdrc_nspire_remove(struct platform_device *pdev)
> -{
> - struct platform_device *ci_pdev = platform_get_drvdata(pdev);
> -
> - ci_hdrc_remove_device(ci_pdev);
> -
> - return 0;
> -}
> -
> -static const struct of_device_id
Re: [PATCH] mm, x86: Skip NUMA_NO_NODE while parsing SLIT
(2013/12/06 0:11), Toshi Kani wrote: On Thu, 2013-12-05 at 19:25 +0900, Yasuaki Ishimatsu wrote: (2013/12/05 6:09), Toshi Kani wrote: When ACPI SLIT table has an I/O locality (i.e. a locality unique to an I/O device), numa_set_distance() emits the warning message below. NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 acpi_numa_slit_init() calls numa_set_distance() with pxm_to_node(), which assumes that all localities have been parsed with SRAT previously. SRAT does not list I/O localities, where as SLIT lists all localities including I/Os. Hence, pxm_to_node() returns NUMA_NO_NODE (-1) for an I/O locality. I/O localities are not supported and are ignored today, but emitting such warning message leads unnecessary confusion. In this case, the warning message should not be shown. But if SLIT table is really broken, the message should be shown. Your patch seems to not care for second case. In the second case, I assume you are worrying about the case of SLIT table with bad locality numbers. Since SLIT is a matrix of the number of localities, it is only possible by making the table bigger than necessary. Such excessive localities are safe to ignore (as they are ignored today) and regular users have nothing to concern about them. The warning message in this case may be helpful for platform vendors to test their firmware, but they have plenty of other methods to verify their SLIT table. I understood it. So, Reviewed-by : Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu Thanks, -Toshi -- 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: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: silicom: fix 'return is not a function, parentheses are not required' in bpctl_mod.c
On Fri, 2013-12-06 at 10:11 +0300, Dan Carpenter wrote: > On Thu, Dec 05, 2013 at 03:29:22PM -0800, Joe Perches wrote: > > On Fri, 2013-12-06 at 02:21 +0300, Dan Carpenter wrote: > > > On Thu, Dec 05, 2013 at 03:09:15PM -0800, Joe Perches wrote: > > > > On Fri, 2013-12-06 at 01:50 +0300, Dan Carpenter wrote: > > > > > On Thu, Dec 05, 2013 at 10:23:53PM +0100, Will Tange wrote: > > > > Ah. > > > > Then maybe use a single ?: or a ! instead > > > > return ret ? 0 : 1; > > or > > return !ret; > > > > You still have to handle the negative. > > if (ret < 0) > return ret; > > return !ret; Of course. Apologies for not being clear. I meant using that ?: or ! after the first if (ret < 0) as you wrote. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: silicom: fix 'return is not a function, parentheses are not required' in bpctl_mod.c
On Thu, Dec 05, 2013 at 03:29:22PM -0800, Joe Perches wrote: > On Fri, 2013-12-06 at 02:21 +0300, Dan Carpenter wrote: > > On Thu, Dec 05, 2013 at 03:09:15PM -0800, Joe Perches wrote: > > > On Fri, 2013-12-06 at 01:50 +0300, Dan Carpenter wrote: > > > > On Thu, Dec 05, 2013 at 10:23:53PM +0100, Will Tange wrote: > > Ah. > > Then maybe use a single ?: or a ! instead > > return ret ? 0 : 1; > or > return !ret; > You still have to handle the negative. if (ret < 0) return ret; return !ret; regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 3/3] dma: Add Freescale eDMA engine driver support
> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Thursday, November 28, 2013 2:08 PM
> To: Lu Jingchang-B35083
> Cc: Mark Rutland; devicet...@vger.kernel.org; Wang Huan-B18965; linux-
> ker...@vger.kernel.org; shawn@linaro.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v6 3/3] dma: Add Freescale eDMA engine driver support
>
> On Wed, Nov 27, 2013 at 09:38:02AM +, Jingchang Lu wrote:
> > > > > > +* DMAMUX
> > > > > > +Required properties:
> > > > >
> > > > > No compatible?
> > > > >
> > > > > Where are DMAMUX nodes expected to live?
> > > > >
> > > > > How to they relate to the eDMA controller in HW? Are they a
> > > > > subcomponent, or a logically separate unit that happens to be
> > > connected?
> > > > [Lu Jingchang-b35083]
> > > > DMAMUX is a multiplexer between dma controller channels and
> peripheral
> > > deivces,
> > > > each DMAMUX provides 16 independently selectable DMA channel
> routers,
> > > and each
> > > > channel router can be assigned to one of the possible peripheral
> DMA
> > > slots.
> > > > So it's not a standalone device, it's just required by the DMA
> > > controller to
> > > > connect the channels and slaves, So it's got by DMA controller's
> > > "fsl,dma-mux" property.
> > > > Thanks!
> > >
> > > Ok.
> > >
> > > I'm not so sure on the way this is described, from the point of view
> of
> > > the device, its DMA channel is wired to the MUX, not to the DMA
> engine
> > > directly:
> > >
> > >+---+
> > > /-|DEVICE0|
> > > | +---+
> > > +-+ +--+
> > > | DMA |===|DMAMUX|
> > > +-+ +--+
> > > | +---+
> > > \-|DEVICE1|
> > >+---+
> > >
> > > If that's the case, I'd expect the DMAMUX to have a #dma-cells and
> > > describe each device as being wired to the mux, and then the mux as
> > > being wired to the DMA. If the MUXes are sub-blocks of the DMA, then
> I'm
> > > not sure why they need to be described at all.
> > >
> > > Currently, the DMA code is handling information that's specific to
> the
> > > MUX (i.e. the channel ID that's specific to the MUX), and that feels
> odd
> > > unless the MUX is a component of the DMA (which if true I'd expect it
> to
> > > be described differently).
> > >
> > Yes, the connection is as your imagination, except for each DMA has two
> MUX.
> > The DMA helper looks the registered DMA engineer for DMA channel
> binding,
> > and the registered DMA engineer is the eDMA node, if binding to DMAMUX,
> > the helper will not find out the dma engineer.
> > The only DMAMUX configuration is programming the slave id into its
> > corresponding register, so its code is handled by the eDMA driver,
> > the DMAMUX is not optional.
> This is fairly common representation of how DMA engines interact with
> slave
> clients via a programmable mux. Now the slave id value in this case
> (which we
> program to mux) needs to be for the client and _not_ for the dmanegine.
> DMA
> engine would have a register to configure the mux value required for the
> transaction.
>
> The dma engine API provides a way to program the slave id (ie mux value)
> and IMO
> this should be a property of slave device (perhaps part of its dma
> resource) and
> used while programming channel. Making it dma driver property makes no
> sense
> here
Since the DMAMUX node in DTS is not a standalone device but tightly-coupled to
the eDMA controller,
Would it be better integrated the DMAMUX info into the eDMA node? Just like the
GIC has an dist and
an cpu interface.
edma0: dma-controller@40018000 {
#dma-cells = <2>;
compatible = "fsl,vf610-edma";
reg = <0x40018000 0x2000>,
<0x40024000 0x1000>,
<0x40025000 0x1000>;
interrupts = <0 8 0x04>, <0 9 0x04>;
interrupt-names = "edma-txrx", "edma-err";
dma-channels = <32>;
clocks = < VF610_CLK_DMAMUX0>,
< VF610_CLK_DMAMUX1>;
};
And Vinod, I notice that there has been some discussion on the slave_id
handling for the SAI audio driver
, which uses the eDMA doing data transfer. Since the driver core infrastructure
would automatically call
the DMA engine help function requesting the channel which be done by the driver
itself, reducing the work
of individual device driver. So for DMA controller like our eDMA which has
slave_id parameter, how about
doing the slave_id configuration during the help call, this can also frees the
driver configuring it, and
make the driver compatible with those who has no slave_id.
Thanks!
Best Regards,
Jingchang
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 6/6] regulator: stw481x-vmmc: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/stw481x-vmmc.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/stw481x-vmmc.c b/drivers/regulator/stw481x-vmmc.c
index f78857b..a7e1526 100644
--- a/drivers/regulator/stw481x-vmmc.c
+++ b/drivers/regulator/stw481x-vmmc.c
@@ -74,7 +74,8 @@ static int stw481x_vmmc_regulator_probe(struct
platform_device *pdev)
config.init_data = of_get_regulator_init_data(>dev,
pdev->dev.of_node);
- stw481x->vmmc_regulator = regulator_register(_regulator, );
+ stw481x->vmmc_regulator = devm_regulator_register(>dev,
+ _regulator, );
if (IS_ERR(stw481x->vmmc_regulator)) {
dev_err(>dev,
"error initializing STw481x VMMC regulator\n");
@@ -85,14 +86,6 @@ static int stw481x_vmmc_regulator_probe(struct
platform_device *pdev)
return 0;
}
-static int stw481x_vmmc_regulator_remove(struct platform_device *pdev)
-{
- struct stw481x *stw481x = dev_get_platdata(>dev);
-
- regulator_unregister(stw481x->vmmc_regulator);
- return 0;
-}
-
static const struct of_device_id stw481x_vmmc_match[] = {
{ .compatible = "st,stw481x-vmmc", },
{},
@@ -105,7 +98,6 @@ static struct platform_driver stw481x_vmmc_regulator_driver
= {
.of_match_table = stw481x_vmmc_match,
},
.probe = stw481x_vmmc_regulator_probe,
- .remove = stw481x_vmmc_regulator_remove,
};
module_platform_driver(stw481x_vmmc_regulator_driver);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] regulator: pfuze100: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/pfuze100-regulator.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 032df37..50c1bf8 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -408,31 +408,18 @@ static int pfuze100_regulator_probe(struct i2c_client
*client,
config.driver_data = pfuze_chip;
config.of_node = match_of_node(i);
- pfuze_chip->regulators[i] = regulator_register(desc, );
+ pfuze_chip->regulators[i] =
+ devm_regulator_register(>dev, desc, );
if (IS_ERR(pfuze_chip->regulators[i])) {
dev_err(>dev, "register regulator%s failed\n",
pfuze100_regulators[i].desc.name);
- ret = PTR_ERR(pfuze_chip->regulators[i]);
- while (--i >= 0)
- regulator_unregister(pfuze_chip->regulators[i]);
- return ret;
+ return PTR_ERR(pfuze_chip->regulators[i]);
}
}
return 0;
}
-static int pfuze100_regulator_remove(struct i2c_client *client)
-{
- int i;
- struct pfuze_chip *pfuze_chip = i2c_get_clientdata(client);
-
- for (i = 0; i < PFUZE100_MAX_REGULATOR; i++)
- regulator_unregister(pfuze_chip->regulators[i]);
-
- return 0;
-}
-
static struct i2c_driver pfuze_driver = {
.id_table = pfuze_device_id,
.driver = {
@@ -441,7 +428,6 @@ static struct i2c_driver pfuze_driver = {
.of_match_table = pfuze_dt_ids,
},
.probe = pfuze100_regulator_probe,
- .remove = pfuze100_regulator_remove,
};
module_i2c_driver(pfuze_driver);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net/fddi: Replace local marco with PCI standard macro
On 2013/12/6 12:44, David Miller wrote: > From: Yijing Wang > Date: Fri, 6 Dec 2013 11:06:28 +0800 > >> On 2013/12/6 6:06, Maciej W. Rozycki wrote: >>> On Thu, 5 Dec 2013, Yijing Wang wrote: >>> Replace local marco DFX_BUS_PCI with PCI standard marco dev_is_pci(). >>> >>> Typos above: marco -> macro >> >> Sorry for the mistake, David, should i need to resend this patch to fix this >> typo error? > > You have to resubmit all of these conversions again because you posted > them before the net-next tree was even open for submissions. > > So you might as well fix the typos etc. while doing so. > > OK, I have resent the two refreshed patches. Thanks! Yijing. -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] regulator: gpio-regulator: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/regulator/gpio-regulator.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c
b/drivers/regulator/gpio-regulator.c
index 13ec94d..fb4120b 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -324,7 +324,8 @@ static int gpio_regulator_probe(struct platform_device
*pdev)
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
}
- drvdata->dev = regulator_register(>desc, );
+ drvdata->dev = devm_regulator_register(>dev, >desc,
+ );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
dev_err(>dev, "Failed to register regulator: %d\n", ret);
@@ -351,8 +352,6 @@ static int gpio_regulator_remove(struct platform_device
*pdev)
{
struct gpio_regulator_data *drvdata = platform_get_drvdata(pdev);
- regulator_unregister(drvdata->dev);
-
gpio_free_array(drvdata->gpios, drvdata->nr_gpios);
kfree(drvdata->states);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] regulator: fixed: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/regulator/fixed.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 5ea64b9..f45cc1ac 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -186,7 +186,8 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
cfg.driver_data = drvdata;
cfg.of_node = pdev->dev.of_node;
- drvdata->dev = regulator_register(>desc, );
+ drvdata->dev = devm_regulator_register(>dev, >desc,
+ );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
dev_err(>dev, "Failed to register regulator: %d\n", ret);
@@ -212,7 +213,6 @@ static int reg_fixed_voltage_remove(struct platform_device
*pdev)
{
struct fixed_voltage_data *drvdata = platform_get_drvdata(pdev);
- regulator_unregister(drvdata->dev);
kfree(drvdata->desc.supply_name);
kfree(drvdata->desc.name);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] regulator: db8500-prcmu: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/regulator/db8500-prcmu.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index a53c11a..846acf2 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -431,17 +431,11 @@ static int db8500_regulator_register(struct
platform_device *pdev,
config.of_node = np;
/* register with the regulator framework */
- info->rdev = regulator_register(>desc, );
+ info->rdev = devm_regulator_register(>dev, >desc, );
if (IS_ERR(info->rdev)) {
err = PTR_ERR(info->rdev);
dev_err(>dev, "failed to register %s: err %i\n",
info->desc.name, err);
-
- /* if failing, unregister all earlier regulators */
- while (--id >= 0) {
- info = _regulator_info[id];
- regulator_unregister(info->rdev);
- }
return err;
}
@@ -530,20 +524,8 @@ static int db8500_regulator_probe(struct platform_device
*pdev)
static int db8500_regulator_remove(struct platform_device *pdev)
{
- int i;
-
ux500_regulator_debug_exit();
- for (i = 0; i < ARRAY_SIZE(dbx500_regulator_info); i++) {
- struct dbx500_regulator_info *info;
- info = _regulator_info[i];
-
- dev_vdbg(rdev_get_dev(info->rdev),
- "regulator-%s-remove\n", info->desc.name);
-
- regulator_unregister(info->rdev);
- }
-
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] regulator: ab8500: use devm_regulator_register()
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/regulator/ab8500.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 0f86695..c625468 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -3005,7 +3005,6 @@ static int ab8500_regulator_register(struct
platform_device *pdev,
struct ab8500 *ab8500 = dev_get_drvdata(pdev->dev.parent);
struct ab8500_regulator_info *info = NULL;
struct regulator_config config = { };
- int err;
/* assign per-regulator data */
info = _regulator.info[id];
@@ -3027,17 +3026,12 @@ static int ab8500_regulator_register(struct
platform_device *pdev,
}
/* register regulator with framework */
- info->regulator = regulator_register(>desc, );
+ info->regulator = devm_regulator_register(>dev, >desc,
+ );
if (IS_ERR(info->regulator)) {
- err = PTR_ERR(info->regulator);
dev_err(>dev, "failed to register regulator %s\n",
info->desc.name);
- /* when we fail, un-register all earlier regulators */
- while (--id >= 0) {
- info = _regulator.info[id];
- regulator_unregister(info->regulator);
- }
- return err;
+ return PTR_ERR(info->regulator);
}
return 0;
@@ -3086,17 +3080,7 @@ static int ab8500_regulator_probe(struct platform_device
*pdev)
static int ab8500_regulator_remove(struct platform_device *pdev)
{
- int i, err;
-
- for (i = 0; i < abx500_regulator.info_size; i++) {
- struct ab8500_regulator_info *info = NULL;
- info = _regulator.info[i];
-
- dev_vdbg(rdev_get_dev(info->regulator),
- "%s-remove\n", info->desc.name);
-
- regulator_unregister(info->regulator);
- }
+ int err;
/* remove regulator debug */
err = ab8500_regulator_debug_exit(pdev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH cgroup/for-3.13-fixes] cgroup: fix oops in cgroup init failure path
On 12/06/2013 01:18 AM, Tejun Heo wrote:
> Hello, Vladimir.
>
> Thanks a lot for the report and fix; however, I really wanna make sure
> that only online css's become visible, so I wrote up a different fix.
> Can you please test this one?
Hi, Tejun
This patch fixes this bug, but I have a couple of questions regarding it.
First, cgroup_load_subsys() also calls css_online(), and if it fails, it
calls cgroup_unload_subsys() to rollback. The latter function executes
the following command:
offline_css(cgroup_css(cgroup_dummy_top, ss));
But since we failed to online_css(), cgroup_css() will return NULL
resulting in another oops.
Second, it's not clear to me why we need the CSS_ONLINE flag at all if
we never assign css's that we fail to online to a cgroup. AFAIU we will
never see such css's, because in all places we call offline_css(),
namely cgroup_destroy_locked() (via kill_css()) and
cgroup_unload_subsys(), we use cgroup_css() which will return NULL for them.
Third, please see commends inline.
Thanks.
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -4399,13 +4399,13 @@ static long cgroup_create(struct cgroup
> css = ss->css_alloc(cgroup_css(parent, ss));
> if (IS_ERR(css)) {
> err = PTR_ERR(css);
> - goto err_free_all;
> + goto err_deactivate;
> }
> css_ar[ss->subsys_id] = css;
>
> err = percpu_ref_init(>refcnt, css_release);
> if (err)
> - goto err_free_all;
> + goto err_deactivate;
>
> init_css(css, ss, cgrp);
> }
> @@ -4417,7 +4417,7 @@ static long cgroup_create(struct cgroup
>*/
> err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
> if (err < 0)
> - goto err_free_all;
> + goto err_deactivate;
> lockdep_assert_held(>d_inode->i_mutex);
>
> cgrp->serial_nr = cgroup_serial_nr_next++;
> @@ -4445,6 +4445,9 @@ static long cgroup_create(struct cgroup
> if (err)
> goto err_destroy;
Before we get here, we call
/* each css holds a ref to the cgroup's dentry and the parent css */
for_each_root_subsys(root, ss) {
struct cgroup_subsys_state *css = css_ar[ss->subsys_id];
dget(dentry);
css_get(css->parent);
}
If we fail to online a css, we will only call
ss->css_free(css);
on it skipping css_put() on parent.
css_put() is called on parent in css_release() on normal destroy path.
>
> + /* @css successfully attached, now owned by @cgrp */
> + css_ar[ss->subsys_id] = NULL;
> +
> if (ss->broken_hierarchy && !ss->warned_broken_hierarchy &&
> parent->parent) {
> pr_warning("cgroup: %s (%d) created nested cgroup for
> controller \"%s\" which has incomplete hierarchy support. Nested cgroups may
> change behavior in the future.\n",
> @@ -4470,15 +4473,7 @@ static long cgroup_create(struct cgroup
>
> return 0;
>
> -err_free_all:
> - for_each_root_subsys(root, ss) {
> - struct cgroup_subsys_state *css = css_ar[ss->subsys_id];
> -
> - if (css) {
> - percpu_ref_cancel_init(>refcnt);
> - ss->css_free(css);
> - }
> - }
> +err_deactivate:
> mutex_unlock(_mutex);
> /* Release the reference count that we took on the superblock */
> deactivate_super(sb);
> @@ -4488,12 +4483,21 @@ err_free_name:
> kfree(rcu_dereference_raw(cgrp->name));
> err_free_cgrp:
> kfree(cgrp);
> - return err;
> + goto out_free_css_ar;
>
> err_destroy:
> cgroup_destroy_locked(cgrp);
> mutex_unlock(_mutex);
> mutex_unlock(>d_inode->i_mutex);
> +out_free_css_ar:
> + for_each_root_subsys(root, ss) {
> + struct cgroup_subsys_state *css = css_ar[ss->subsys_id];
> +
> + if (css) {
> + percpu_ref_cancel_init(>refcnt);
> + ss->css_free(css);
> + }
> + }
> return err;
> }
>
> @@ -4650,10 +4654,14 @@ static int cgroup_destroy_locked(struct
> /*
>* Initiate massacre of all css's. cgroup_destroy_css_killed()
>* will be invoked to perform the rest of destruction once the
> - * percpu refs of all css's are confirmed to be killed.
> + * percpu refs of all css's are confirmed to be killed. Not all
> + * css's may be present if @cgrp failed init half-way.
>*/
> - for_each_root_subsys(cgrp->root, ss)
> - kill_css(cgroup_css(cgrp, ss));
> + for_each_root_subsys(cgrp->root, ss) {
> + struct cgroup_subsys_state *css = cgroup_css(cgrp, ss);
> + if (css)
> + kill_css(cgroup_css(cgrp, ss));
> + }
>
> /*
>* Mark @cgrp dead. This prevents further task migration and child
--
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
>> I am not sure if this question is related, uprobes or ftrace code does >> not define __kprobes, so is it safe to place kprobe on uprobes or >> ftrace code? > > Yes, it is "safe" in qualitative meaning. But for ftrace code, it could > give a performance impact by miss-hitting. Since uprobe is independent > from kprobe, it should work. > >> Is it expected from arch code to support such cases? > > Yes, the arch dependent implementation is the key. If it shares some > code which can be called from miss-hit path, it should be blacklisted. well, isn't the blacklist only for those routines that can not be handled or may crash kernel, like the code sections called from exception kprobes exception handlers etc? suppose if the probe on routine can miss-hit (probes re-cursing) but can be handled, it's only a quantitative issue (i.e. performance impact) so it should be *user's* problem right? I mean, as you said earlier about having white-list or a performance gatekeeper (systemtap), one can avoid such cases by white list or removing miss-hit probes dynamically. But a blacklisting a symbol means placing a probe on that *can not be handled* and can crash the system, is it correct? Thanks, Sandeepa > > Thank you, > > -- > Masami HIRAMATSU > IT Management Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu...@hitachi.com > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/10] PCI: Destroy pci dev only once
On Mon, Dec 2, 2013 at 6:49 AM, Rafael J. Wysocki wrote:
>
> Scenario 5: pci_stop_and_remove_bus_device() is run concurrently
> for a device and its parent bridge via remove_callback().
>
> In that case both code paths attempt to acquire
> pci_remove_rescan_mutex. If the child device removal acquires
> it first, there will be no problems. However, if the parent
> bridge removal acquires it first, it will eventually execute
> pci_destroy_dev() for the child device, but that device will
> not be freed yet due to the reference held by the concurrent
> child removal. Consequently, both pci_stop_bus_device() and
> pci_remove_bus_device() will be executed for that device
> unnecessarily and pci_destroy_dev() will see a corrupted list
> head in that object. Moreover, an excess put_device() will
> be executed for that device in that case which may lead to a
> use-after-free in the final kobject_put() done by
> sysfs_schedule_callback_work().
>
> Index: linux-pm/include/linux/pci.h
> ===
> --- linux-pm.orig/include/linux/pci.h
> +++ linux-pm/include/linux/pci.h
> @@ -321,6 +321,7 @@ struct pci_dev {
> unsigned intmultifunction:1;/* Part of multi-function device */
> /* keep track of device state */
> unsigned intis_added:1;
> + unsigned intis_gone:1;
> unsigned intis_busmaster:1; /* device is busmaster */
> unsigned intno_msi:1; /* device may not use msi */
> unsigned intblock_cfg_access:1; /* config space access is
> blocked */
> Index: linux-pm/drivers/pci/remove.c
> ===
> --- linux-pm.orig/drivers/pci/remove.c
> +++ linux-pm/drivers/pci/remove.c
> @@ -34,6 +34,7 @@ static void pci_stop_dev(struct pci_dev
>
> static void pci_destroy_dev(struct pci_dev *dev)
> {
> + dev->is_gone = 1;
> device_del(>dev);
>
> down_write(_bus_sem);
> @@ -109,8 +110,10 @@ static void pci_remove_bus_device(struct
> */
> void pci_stop_and_remove_bus_device(struct pci_dev *dev)
> {
> - pci_stop_bus_device(dev);
> - pci_remove_bus_device(dev);
> + if (!dev->is_gone) {
> + pci_stop_bus_device(dev);
> + pci_remove_bus_device(dev);
> + }
> }
> EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
>
Yes, above change should address sys double remove problem.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI/Button: Fix enable Button GPEs twice
Button GPEs have been enabled in the acpi_wake_device_init() during
boot and Button driver enables these GPEs second time. This causes
disabling these gpes via sysfs interface requires twice "echo disable
> /sys/firmware/acpi/interrupts/gpeXXX". This patch is to remove
related code in the Button driver.
Signed-off-by: Lan Tianyu
---
drivers/acpi/button.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 9e3a6cb..6643f2d 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -406,15 +406,9 @@ static int acpi_button_add(struct acpi_device *device)
lid_device = device;
}
- if (device->wakeup.flags.valid) {
- /* Button's GPE is run-wake GPE */
- acpi_enable_gpe(device->wakeup.gpe_device,
- device->wakeup.gpe_number);
- if (!device_may_wakeup(>dev)) {
- device_set_wakeup_enable(>dev, true);
- button->wakeup_enabled = true;
- }
- }
+ /* Button GPEs have been enalbed in the acpi_wakeup_device_list()*/
+ if (device->wakeup.flags.valid)
+ button->wakeup_enabled = true;
printk(KERN_INFO PREFIX "%s [%s]\n", name, acpi_device_bid(device));
return 0;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
Hello Arnd,
> Do you have a strong reason to have your own defconfig file? We
> currently try to consolidate as much as possible into
> multi_v7_defconfig, so please see if you can extend that instead to
> do what you need.
There's no reason why we can't use the multi-platform defconfig. I'll
make sure our platform uses it in the next revision.
> This seems like stuff that should go into the device drivers for the
> respective hardware blocks, not into platform code.
Understood. I'm not sure if you recall this [1] conversation, but short
of having a big array of registers offsets per chip ID (which will
probably grow to 10 or more), leveraging the DT to let the bootloader
tell the kernel these randomly-located registers are proved to be very
lightweight.
Seems like there's one thing I could possibly factor out into a separate
driver... the registers that assert a chip reset (sw-master-reset-reg).
Maybe I could register a reset-controller driver specifically for this
purpose?
> We try hard to avoid having register available this early and outside
> of device drivers. Can you try to make at least some (if not all) of
> these more regular, and provide specific comments in the code why this
> is not possible for the others?
Just to be sure, you're asking to reduce our dependence on touching
these machine-specific registers?
I will incorporate all of your suggestions into the next revision of the
patch set. Thank you for the review!
Regards,
Marc
[1] http://www.spinics.net/lists/arm-kernel/msg288567.html
On 12/3/2013 7:01 AM, Arnd Bergmann wrote:
> On Wednesday 27 November 2013, Marc Carino wrote:
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 5765abf..266c699 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -94,6 +94,17 @@ choice
>> depends on ARCH_BCM2835
>> select DEBUG_UART_PL01X
>>
>> +config DEBUG_BRCMSTB_UART
>> +bool "Use BRCMSTB UART for low-level debug"
>> +depends on ARCH_BRCMSTB
>> +select DEBUG_UART_8250
>> +help
>> + Say Y here if you want the debug print routines to direct
>> + their output to the first serial port on these devices.
>> +
>> + If you have a Broadcom STB chip and would like early print
>> + messages to appear over the UART, select this option.
>> +
>> config DEBUG_CLPS711X_UART1
>> bool "Kernel low-level debugging messages via UART1"
>> depends on ARCH_CLPS711X
>
> Can you split out the debug UART changes into a separate patch?
>
>> diff --git a/arch/arm/configs/brcmstb_defconfig
>> b/arch/arm/configs/brcmstb_defconfig
>> new file mode 100644
>> index 000..1741d92
>> --- /dev/null
>> +++ b/arch/arm/configs/brcmstb_defconfig
>> @@ -0,0 +1,127 @@
>> +CONFIG_CROSS_COMPILE="arm-linux-"
>> +CONFIG_KERNEL_LZO=y
>> +CONFIG_SYSVIPC=y
>> +CONFIG_POSIX_MQUEUE=y
>> +CONFIG_LOG_BUF_SHIFT=14
>> +CONFIG_SYSFS_DEPRECATED=y
>> +CONFIG_RELAY=y
>> +CONFIG_BLK_DEV_INITRD=y
>
> Do you have a strong reason to have your own defconfig file? We currently
> try to consolidate as much as possible into multi_v7_defconfig, so please
> see if you can extend that instead to do what you need.
>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index 9fe6d88..9179259 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -31,6 +31,24 @@ config ARCH_BCM_MOBILE
>>BCM11130, BCM11140, BCM11351, BCM28145 and
>>BCM28155 variants.
>>
>> +config ARCH_BRCMSTB
>> +bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
>> +depends on MMU
>> +select ARM_ARCH_TIMER
>> +select ARM_GIC
>> +select BRCMSTB
>> +select MIGHT_HAVE_PCI
>> +select HAVE_SMP
>> +select USE_OF
>> +select CPU_V7
>> +select GENERIC_CLOCKEVENTS
>
> Some of these are already implied by ARCH_MULTI_V7 and can be dropped
> from this list.
>
>> +struct platform_regs brcm_plat_regs;
>> +
>> +/***
>> + * STB CPU (main application processor)
>> + ***/
>> +
>> +static struct map_desc brcmstb_io_map[] __initdata = {
>> +{
>> +.virtual = (unsigned long)BRCMSTB_PERIPH_VIRT,
>> +.pfn = __phys_to_pfn(BRCMSTB_PERIPH_PHYS),
>> +.length = BRCMSTB_PERIPH_LENGTH,
>> +.type= MT_DEVICE,
>> +},
>> +};
>
> Why do you need a static I/O mapping? You should not rely on hardcoded
> virtual or physical addresses in general.
>
>> +static struct node_reg sun_top_ctrl_regs[] __initdata = {
>> +{"reset-source-enable-reg", _plat_regs.reset_source_enable_reg},
>> +{"sw-master-reset-reg", _plat_regs.sw_master_reset_reg},
>> +{NULL, NULL}
>> +};
>> +
>> +static struct node_reg cpu_biu_ctrl_regs[] __initdata = {
>> +{"cpu-reset-config-reg",
[PATCH net v2 2/2] 3c59x/net: Use dev_is_pci() instead of hardcoding
Use PCI standard macro dev_is_pci() instead of hardcoding. Signed-off-by: Yijing Wang --- drivers/net/ethernet/3com/3c59x.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c index ad5272b..af24c3c 100644 --- a/drivers/net/ethernet/3com/3c59x.c +++ b/drivers/net/ethernet/3com/3c59x.c @@ -693,7 +693,7 @@ DEFINE_WINDOW_IO(16) DEFINE_WINDOW_IO(32) #ifdef CONFIG_PCI -#define DEVICE_PCI(dev) (((dev)->bus == _bus_type) ? to_pci_dev((dev)) : NULL) +#define DEVICE_PCI(dev) ((dev_is_pci(dev)) ? to_pci_dev((dev)) : NULL) #else #define DEVICE_PCI(dev) NULL #endif -- 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 net v2 1/2] net/fddi: Replace local macro with PCI standard macro
Replace local macro DFX_BUS_PCI() with PCI standard macro
dev_is_pci().
Acked-by: Maciej W. Rozycki
Signed-off-by: Yijing Wang
---
drivers/net/fddi/defxx.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
index 0b40e1c..0344f71 100644
--- a/drivers/net/fddi/defxx.c
+++ b/drivers/net/fddi/defxx.c
@@ -241,12 +241,6 @@ static char version[] =
*/
#define NEW_SKB_SIZE (PI_RCV_DATA_K_SIZE_MAX+128)
-#ifdef CONFIG_PCI
-#define DFX_BUS_PCI(dev) (dev->bus == _bus_type)
-#else
-#define DFX_BUS_PCI(dev) 0
-#endif
-
#ifdef CONFIG_EISA
#define DFX_BUS_EISA(dev) (dev->bus == _bus_type)
#else
@@ -436,7 +430,7 @@ static void dfx_port_read_long(DFX_board_t *bp, int offset,
u32 *data)
static void dfx_get_bars(struct device *bdev,
resource_size_t *bar_start, resource_size_t *bar_len)
{
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
@@ -518,7 +512,7 @@ static const struct net_device_ops dfx_netdev_ops = {
static int dfx_register(struct device *bdev)
{
static int version_disp;
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
const char *print_name = dev_name(bdev);
@@ -667,7 +661,7 @@ static void dfx_bus_init(struct net_device *dev)
{
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp->bus_dev;
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
@@ -813,7 +807,7 @@ static void dfx_bus_uninit(struct net_device *dev)
{
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp->bus_dev;
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
u8 val;
@@ -967,7 +961,7 @@ static int dfx_driver_init(struct net_device *dev, const
char *print_name,
{
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp->bus_dev;
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
@@ -1877,7 +1871,7 @@ static irqreturn_t dfx_interrupt(int irq, void *dev_id)
struct net_device *dev = dev_id;
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp->bus_dev;
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
@@ -3579,7 +3573,7 @@ static void dfx_unregister(struct device *bdev)
{
struct net_device *dev = dev_get_drvdata(bdev);
DFX_board_t *bp = netdev_priv(dev);
- int dfx_bus_pci = DFX_BUS_PCI(bdev);
+ int dfx_bus_pci = dev_is_pci(bdev);
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
resource_size_t bar_start = 0; /* pointer to port */
--
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 V3 0/4] ARM: tegra: convert dts files of all Tegra platforms to use pinctrl defines
On Friday 06 December 2013 05:03 AM, Stephen Warren wrote: On 12/05/2013 03:44 AM, Laxman Dewangan wrote: This patch series convert dts files of all Tegra's platforms to use the pinctron dt-binding macro for better readability. I think this series looks fine now; I'll apply soon pending what happens with the DMA/reset/ binding rework. There are quite a few typos/spelling/capitalization mistakes in the commit descriptions, but I'll fix them up when applying. Thanks for review. I like to also update the dt binding document to use thes macro. Will post the chnage for doc update also. And I want to refer this for t124 dt binding doc of pinctrl also. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: tegra: add pinmux controller driver for Tegra124
On Friday 06 December 2013 05:00 AM, Stephen Warren wrote:
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
From: Ashwini Ghuge
This adds a driver for the Tegra124 pinmux, and required
parameterization data for Tegra124.
The driver uses the common Tegra pincontrol driver utility
functions to implement the majority of the driver.
This driver is not compatible with the earlier NVIDIA's SoCs,
hence add new compatibile as "nvidia,tegra124-pinmux".
Originally written by Ashwini Gguhe.
ldewangan:
- cleanup the patches,
- Fix address issue.
IIRC, Thierry mentioned he had some fixes in his local branch for this
driver. Thierry, can you please confirm/deny this?
I made the following comment on the version Ashwini posted, which hasn't
been addressed yet:
A day or two ago during upstream review:
Yes, we have some missing entry and I responded into other mail thread.
I will post the diff here to complete.
+static const struct tegra_function tegra124_functions[] = {
...
+ FUNCTION(i2c1),
+ FUNCTION(i2c2),
+ FUNCTION(i2c3),
+ FUNCTION(i2c4),
+ FUNCTION(i2cpwr),
Is that complete? Tegra124 apparently has 6 I2C controllers. Are the
pins for the new sixth controller (0x7000d100) not affected by the pinmux?
That said, if we find things are missing, I suppose we can add them
later without breaking existing ABI. Breakage would only happen if we
had to change/remove something.
During downstream review quite a while ago I also said:
I2C6 pinmux is not in this controller, it is dpaux controller and we
have not supported this. This require little bit different handling. I
have already downstream bug for support this. Will add you in loop so
that single fix can work for mainline and downstream.
Other than I2C6, some other mux are missing.
+static const struct pinctrl_pin_desc tegra124_pins[] = {
There are two spaces before "tegra124_pins[]".
+static const char * const gmi_groups[] = {
+ "uart2_cts_n_pj5",
+ "uart2_rts_n_pj6",
+ "uart3_txd_pw6",
+ "uart3_rxd_pw7",
+ "uart3_cts_n_pa1",
+ "uart3_rts_n_pc0",
+
+ "pu0",
It'd be best not to have blank lines in the middle of arrays. The same comment
exists elsewhere in the
file, so make sure you search the whole file.
Nits:
- There are some cases of multiple blank lines back-to-back.
- There's a blank line at the end of the file.
Aside from those minor issues, patches 1/4 and 4/4,
Acked-by: Stephen Warren
(BTW, those 2 patches would go through the pinctrl tree, and patches 2/4
and 3/4 would go through the Tegra tree. You generally shouldn't posted
patches that will be applied to different trees in the same series,
since there aren't dependencies).
Fine.
Should I sent the diff or full change? I think full change as this need
to go on pincontrol subsystem, not in Tegra.
Thanks,
Laxman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/10] PCI: Destroy pci dev only once
On Thu, Dec 5, 2013 at 5:21 PM, Rafael J. Wysocki wrote: >> >> The use-after-free problems *sound* like a reference counting issue. >> Yinghai's patch [1] should fix some of this; how much is left after >> that? >> >> [1] >> http://lkml.kernel.org/r/1385851238-21085-4-git-send-email-ying...@kernel.org > > Hmm, no. Do you mean https://patchwork.kernel.org/patch/3261171/ ? should be https://patchwork.kernel.org/patch/3261001/ [v3,03/12] PCI: Move resources and bus_list releasing to pci_release_dev move down list_del(_dev->bus_list). Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/urgent] sched: Check sched_domain before computing group power
On Wed, Nov 27, 2013 at 11:07 PM, Yinghai Lu wrote: > On Wed, Nov 27, 2013 at 7:02 PM, David Rientjes wrote: > maybe not related, now in another system, linus's tree + Srikar's patch. > > got > > [ 33.546361] divide error: [#1] > SMP > [ 33.589436] Modules linked in: > [ 33.592869] CPU: 15 PID: 567 Comm: kworker/u482:0 Not tainted > 3.13.0-rc1-yh-00324-gcf1be1c-dirty #10 > [ 33.603075] Hardware name: Oracle Corporation > [ 33.609571] calling ipc_ns_init+0x0/0x14 @ 1 > [ 33.609575] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs > [ 33.609577] calling init_mmap_min_addr+0x0/0x16 @ 1 > [ 33.609579] initcall init_mmap_min_addr+0x0/0x16 returned 0 after 0 usecs > [ 33.609583] calling init_cpufreq_transition_notifier_list+0x0/0x1b @ 1 > [ 33.609621] initcall init_cpufreq_transition_notifier_list+0x0/0x1b > returned 0 after 0 usecs > [ 33.609624] calling net_ns_init+0x0/0xfa @ 1 > [ 33.677194] task: 897c5ba5c8c0 ti: 897c5ba8e000 task.ti: > 897c5ba8e000 > [ 33.685558] RIP: 0010:[] [] > find_busiest_group+0x2ac/0x880 > [ 33.695310] RSP: :897c5ba8f9a8 EFLAGS: 00010046 > [ 33.701253] RAX: 0001dfff RBX: RCX: > 0001e000 > [ 33.709226] RDX: RSI: 0078 RDI: > > [ 33.717198] RBP: 897c5ba8fb08 R08: R09: > > [ 33.725178] R10: R11: 0001e000 R12: > 897c5ba8fa90 > [ 33.733156] R13: 897c5ad61d80 R14: R15: > 897c5ba8fba0 > [ 33.741132] FS: () GS:897d7c20() > knlGS: > [ 33.750164] CS: 0010 DS: ES: CR0: 80050033 > [ 33.756593] CR2: 0168 CR3: 02a14000 CR4: > 001407e0 > [ 33.764571] Stack: > [ 33.766822] 0046 0048 > > [ 33.775141] 897c5ad61d98 897c5ba8fa20 0036 > 03ab > [ 33.783461] 03ab 0139 44e8 > 00010003 > [ 33.791789] Call Trace: > [ 33.794549] [] load_balance+0x1c8/0x8d0 > [ 33.800701] [] ? __lock_acquire+0xadb/0xce0 > [ 33.807222] [] idle_balance+0x101/0x1c0 > [ 33.813355] [] ? idle_balance+0x44/0x1c0 > [ 33.819618] [] __schedule+0x2cb/0xa10 > [ 33.825584] [] ? trace_hardirqs_off_caller+0x28/0x160 > [ 33.833089] [] ? trace_hardirqs_off+0xd/0x10 > [ 33.839731] [] ? local_clock+0x34/0x60 > [ 33.845788] [] ? worker_thread+0x2db/0x370 > [ 33.852241] [] ? _raw_spin_unlock_irq+0x30/0x40 > [ 33.859150] [] schedule+0x65/0x70 > [ 33.864700] [] worker_thread+0x2e0/0x370 > [ 33.870932] [] ? trace_hardirqs_on+0xd/0x10 > [ 33.877472] [] ? manage_workers.isra.17+0x330/0x330 > [ 33.884789] [] kthread+0x108/0x110 > [ 33.890441] [] ? __init_kthread_worker+0x70/0x70 > [ 33.897465] [] ret_from_fork+0x7c/0xb0 > [ 33.903504] [] ? __init_kthread_worker+0x70/0x70 > [ 33.910508] Code: 89 85 b8 fe ff ff 49 8b 45 10 41 8b 75 0c 44 8b > 50 08 44 8b 58 04 89 f0 48 c1 e0 0a 45 89 d1 49 8d 44 01 ff 48 89 c2 > 48 c1 fa 3f <49> f7 f9 31 d2 49 89 c1 89 f0 44 89 de 41 f7 f1 48 81 c6 > 00 02 > [ 33.932375] RIP [] find_busiest_group+0x2ac/0x880 > [ 33.939491] RSP > [ 33.943418] ---[ end trace 7a833c0cac54cac8 ]--- Hi, PeterZ, This divide_by_zero could be workaround with attached patch. Yinghai --- kernel/sched/core.c |3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6/kernel/sched/core.c === --- linux-2.6.orig/kernel/sched/core.c +++ linux-2.6/kernel/sched/core.c @@ -5737,6 +5737,9 @@ static int __sdt_alloc(const struct cpum if (!sgp) return -ENOMEM; + /* avoid divide-by-zero in sg_capacity() */ + sgp->power_orig = 1; + *per_cpu_ptr(sdd->sgp, j) = sgp; } }
Re: [PATCH 1/4] pinctrl: tegra: Add devicetree binding document for Tegra124
On Friday 06 December 2013 04:47 AM, Stephen Warren wrote: On 12/05/2013 03:57 AM, Laxman Dewangan wrote: This device tree binding document describes the Tegra124 pincontrol DT bindings. This document lists all valid properties, names, mux options of Tegra124 pins. Is this a repost of what Ashwini sent a few weeks back, or V2? If V2, it'd be useful to know what changed... I am not aware that Ashwini already sent back. I did not get chance to talk to her on this. I was thinking that it is still in internal review. Anyhow, I compare the downstream to your linux-next-common and found some diff. Something fixed in your tree which need downstream and something fixed in downstream which need to upstream. :) One diff is Mux enums are: TEGRA_MUX_SATA, TEGRA_MUX_CCLA, TEGRA_MUX_PE0, TEGRA_MUX_PE, TEGRA_MUX_PE1, TEGRA_MUX_DP, TEGRA_MUX_RTCK, TEGRA_MUX_SYS, TEGRA_MUX_CLK, TEGRA_MUX_TMDS, }; Functions definitions are: FUNCTION(sata), FUNCTION(ccla), FUNCTION(rtck), FUNCTION(pe0), FUNCTION(pe), FUNCTION(pe1), FUNCTION(dp), I think I will post the patch to fix this issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
(2013/12/05 22:08), Sandeepa Prabhu wrote: >> OK, I think the kprobe is like a strong medicine, not a toy, >> since it can intercept most of the kernel functions which >> may process a sensitive user private data. Thus even if we >> fix all bugs and make it safe, I don't think we can open >> it for all users (of course, there should be a knob to open >> for any or restricted users.) >> >>> So we need both a maintainable and a sane/safe solution, and I'd like >>> to apply the whole thing at once and be at ease that the solution is >>> round. We should have done this years ago. >> >> For the safeness of kprobes, I have an idea; introduce a whitelist >> for dynamic events. AFAICS, the biggest unstable issue of kprobes >> comes from putting *many* probes on the functions called from tracers. >> >> It doesn't crash the kernel but slows down so much, because every >> probes hit many other nested miss-hit probes. This gives us a big >> performance impact. However, on the other side, this kind of feature >> can be used *for debugging* static trace events by dynamic one if we >> carefully use a small number of probes on such functions. :) >> >> Thus, I think we can restrict users from probing such functions by >> using a whitelist which ftrace does already have; >> available_filter_functions :) > I am not sure if this question is related, uprobes or ftrace code does > not define __kprobes, so is it safe to place kprobe on uprobes or > ftrace code? Yes, it is "safe" in qualitative meaning. But for ftrace code, it could give a performance impact by miss-hitting. Since uprobe is independent from kprobe, it should work. > Is it expected from arch code to support such cases? Yes, the arch dependent implementation is the key. If it shares some code which can be called from miss-hit path, it should be blacklisted. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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/
[net-next PATCH v3 3/6] macvtap: remove the dead branch
From: Zhi Yong Wu Signed-off-by: Zhi Yong Wu --- drivers/net/macvtap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 9093004..d271fb4 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -779,8 +779,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q, return -EINVAL; ret = macvtap_skb_to_vnet_hdr(skb, _hdr); - if (ret) - return ret; if (memcpy_toiovecend(iv, (void *)_hdr, 0, sizeof(vnet_hdr))) return -EFAULT; -- 1.7.6.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/
[net-next PATCH v3 2/6] vhost: adjust vhost_dev_init() to be void
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
Acked-by: Michael S. Tsirkin
---
drivers/vhost/net.c |4 ++--
drivers/vhost/scsi.c |2 +-
drivers/vhost/test.c |3 +--
drivers/vhost/vhost.c |4 +---
drivers/vhost/vhost.h |2 +-
5 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 0554785..9a68409 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -683,7 +683,7 @@ static int vhost_net_open(struct inode *inode, struct file
*f)
struct vhost_net *n = kmalloc(sizeof *n, GFP_KERNEL);
struct vhost_dev *dev;
struct vhost_virtqueue **vqs;
- int r, i;
+ int i;
if (!n)
return -ENOMEM;
@@ -706,7 +706,7 @@ static int vhost_net_open(struct inode *inode, struct file
*f)
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
}
- r = vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
+ vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT, dev);
vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN, dev);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 3164680..1e4c75c 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1417,7 +1417,7 @@ static int vhost_scsi_open(struct inode *inode, struct
file *f)
vqs[i] = >vqs[i].vq;
vs->vqs[i].vq.handle_kick = vhost_scsi_handle_kick;
}
- r = vhost_dev_init(>dev, vqs, VHOST_SCSI_MAX_VQ);
+ vhost_dev_init(>dev, vqs, VHOST_SCSI_MAX_VQ);
tcm_vhost_init_inflight(vs, NULL);
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 99cb960..c2a54fb 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -104,7 +104,6 @@ static int vhost_test_open(struct inode *inode, struct file
*f)
struct vhost_test *n = kmalloc(sizeof *n, GFP_KERNEL);
struct vhost_dev *dev;
struct vhost_virtqueue **vqs;
- int r;
if (!n)
return -ENOMEM;
@@ -117,7 +116,7 @@ static int vhost_test_open(struct inode *inode, struct file
*f)
dev = >dev;
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
- r = vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX);
+ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX);
f->private_data = n;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 69068e0..78987e4 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -290,7 +290,7 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
vhost_vq_free_iovecs(dev->vqs[i]);
}
-long vhost_dev_init(struct vhost_dev *dev,
+void vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue **vqs, int nvqs)
{
struct vhost_virtqueue *vq;
@@ -319,8 +319,6 @@ long vhost_dev_init(struct vhost_dev *dev,
vhost_poll_init(>poll, vq->handle_kick,
POLLIN, dev);
}
-
- return 0;
}
EXPORT_SYMBOL_GPL(vhost_dev_init);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 4465ed5..35eeb2a 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -127,7 +127,7 @@ struct vhost_dev {
struct task_struct *worker;
};
-long vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs, int
nvqs);
+void vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs, int
nvqs);
long vhost_dev_set_owner(struct vhost_dev *dev);
bool vhost_dev_has_owner(struct vhost_dev *dev);
long vhost_dev_check_owner(struct vhost_dev *);
--
1.7.6.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/
[net-next PATCH v3 5/6] macvtap: remove unused parameter in macvtap_do_read()
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/macvtap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index f599c47..4c6f84c 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -819,7 +819,7 @@ done:
return ret ? ret : copied;
}
-static ssize_t macvtap_do_read(struct macvtap_queue *q, struct kiocb *iocb,
+static ssize_t macvtap_do_read(struct macvtap_queue *q,
const struct iovec *iv, unsigned long len,
int noblock)
{
@@ -870,7 +870,7 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const
struct iovec *iv,
goto out;
}
- ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK);
+ ret = macvtap_do_read(q, iv, len, file->f_flags & O_NONBLOCK);
ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */
out:
return ret;
@@ -1102,7 +1102,7 @@ static int macvtap_recvmsg(struct kiocb *iocb, struct
socket *sock,
int ret;
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
return -EINVAL;
- ret = macvtap_do_read(q, iocb, m->msg_iov, total_len,
+ ret = macvtap_do_read(q, m->msg_iov, total_len,
flags & MSG_DONTWAIT);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
--
1.7.6.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/
[net-next PATCH v3 4/6] macvtap: adjust macvtap_skb_to_vnet_hdr() to be void
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/macvtap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index d271fb4..f599c47 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -588,7 +588,7 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb,
return 0;
}
-static int macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
+static void macvtap_skb_to_vnet_hdr(const struct sk_buff *skb,
struct virtio_net_hdr *vnet_hdr)
{
memset(vnet_hdr, 0, sizeof(*vnet_hdr));
@@ -619,8 +619,6 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff
*skb,
} else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
-
- return 0;
}
/* Get packet from user space buffer */
@@ -778,7 +776,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if ((len -= vnet_hdr_len) < 0)
return -EINVAL;
- ret = macvtap_skb_to_vnet_hdr(skb, _hdr);
+ macvtap_skb_to_vnet_hdr(skb, _hdr);
if (memcpy_toiovecend(iv, (void *)_hdr, 0,
sizeof(vnet_hdr)))
return -EFAULT;
--
1.7.6.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/
[net-next PATCH v3 6/6] tun: remove unused parameter in tun_do_read()
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/tun.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 782e38b..f9c935a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1289,8 +1289,7 @@ done:
}
static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
- struct kiocb *iocb, const struct iovec *iv,
- ssize_t len, int noblock)
+ const struct iovec *iv, ssize_t len, int noblock)
{
DECLARE_WAITQUEUE(wait, current);
struct sk_buff *skb;
@@ -1353,7 +1352,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const
struct iovec *iv,
goto out;
}
- ret = tun_do_read(tun, tfile, iocb, iv, len,
+ ret = tun_do_read(tun, tfile, iv, len,
file->f_flags & O_NONBLOCK);
ret = min_t(ssize_t, ret, len);
out:
@@ -1452,7 +1451,7 @@ static int tun_recvmsg(struct kiocb *iocb, struct socket
*sock,
SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
- ret = tun_do_read(tun, tfile, iocb, m->msg_iov, total_len,
+ ret = tun_do_read(tun, tfile, m->msg_iov, total_len,
flags & MSG_DONTWAIT);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
--
1.7.6.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/
[net-next PATCH v3 0/6] net: some cleanups
From: Zhi Yong Wu Since net-next is open now, it's time to post them again. Zhi Yong Wu (6): vhost: remove the dead branch vhost: adjust vhost_dev_init() to be void macvtap: remove the dead branch macvtap: adjust macvtap_skb_to_vnet_hdr() to be void macvtap: remove unused parameter in macvtap_do_read() tun: remove unused parameter in tun_do_read() drivers/net/macvtap.c | 14 +- drivers/net/tun.c |7 +++ drivers/vhost/net.c |9 ++--- drivers/vhost/scsi.c |7 +-- drivers/vhost/test.c |8 +--- drivers/vhost/vhost.c |4 +--- drivers/vhost/vhost.h |2 +- 7 files changed, 14 insertions(+), 37 deletions(-) -- 1.7.6.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/
[net-next PATCH v3 1/6] vhost: remove the dead branch
From: Zhi Yong Wu
Since vhost_dev_init() forever return 0, some branches are never run,
therefore need to be removed.
Signed-off-by: Zhi Yong Wu
Acked-by: Michael S. Tsirkin
---
drivers/vhost/net.c |5 -
drivers/vhost/scsi.c |5 -
drivers/vhost/test.c |5 -
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 831eb4f..0554785 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -707,11 +707,6 @@ static int vhost_net_open(struct inode *inode, struct file
*f)
n->vqs[i].sock_hlen = 0;
}
r = vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
- if (r < 0) {
- kfree(n);
- kfree(vqs);
- return r;
- }
vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, POLLOUT, dev);
vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, POLLIN, dev);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index f175629..3164680 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1421,14 +1421,9 @@ static int vhost_scsi_open(struct inode *inode, struct
file *f)
tcm_vhost_init_inflight(vs, NULL);
- if (r < 0)
- goto err_init;
-
f->private_data = vs;
return 0;
-err_init:
- kfree(vqs);
err_vqs:
vhost_scsi_free(vs);
err_vs:
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 339eae8..99cb960 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -118,11 +118,6 @@ static int vhost_test_open(struct inode *inode, struct
file *f)
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
r = vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX);
- if (r < 0) {
- kfree(vqs);
- kfree(n);
- return r;
- }
f->private_data = n;
--
1.7.6.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 PATCH tip 0/5] tracing filters with BPF
On Thu, Dec 5, 2013 at 12:40 PM, Alexei Starovoitov wrote:
>> On Tue, Dec 3, 2013 at 4:01 PM, Andi Kleen wrote:
>>>
>>> Can you do some performance comparison compared to e.g. ktap?
>>> How much faster is it?
>
> Did simple ktap test with 1M alloc_skb/kfree_skb toy test from earlier email:
> trace skb:kfree_skb {
> if (arg2 == 0x100) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 350315 (usecs)
>
> baseline without any tracing:
> 1M skb alloc/free 145400 (usecs)
>
> then equivalent bpf test:
> void filter(struct bpf_context *ctx)
> {
> void *loc = (void *)ctx->regs.dx;
> if (loc == 0x100) {
> struct sk_buff *skb = (struct sk_buff *)ctx->regs.si;
> char fmt[] = "skb %p loc %p\n";
> bpf_trace_printk(fmt, sizeof(fmt), (long)skb, (long)loc, 0);
> }
> }
> 1M skb alloc/free 183214 (usecs)
>
> so with one 'if' condition the difference ktap vs bpf is 350-145 vs 183-145
>
> obviously ktap is an interpreter, so it's not really fair.
>
> To make it really unfair I did:
> trace skb:kfree_skb {
> if (arg2 == 0x100 || arg2 == 0x200 || arg2 == 0x300 || arg2 == 0x400
> ||
> arg2 == 0x500 || arg2 == 0x600 || arg2 == 0x700 || arg2 == 0x800
> ||
> arg2 == 0x900 || arg2 == 0x1000) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 484280 (usecs)
>
I've lost my mind for a while. :)
If bpf only focus on filter, then it's not good to compare with ktap
like that, since
ktap can easily make use on current kernel filter, you should use below script:
trace skb:kfree_skb /location == 0x100 || location == 0x200 || .../ {
printf("%x %x\n", arg1, arg2)
}
As ktap is a user of current simple kernel tracing filter, I fully
agree with Steven,
"it can be an add on, but not a replacement."
Thanks,
Jovi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] macvtap: update file current position
From: Zhi Yong Wu Signed-off-by: Zhi Yong Wu --- drivers/net/macvtap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 9093004..957cc5c 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -876,6 +876,8 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv, ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK); ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */ + if (ret > 0) + iocb->ki_pos = ret; out: return ret; } -- 1.7.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tun: update file current position
From: Zhi Yong Wu Signed-off-by: Zhi Yong Wu --- drivers/net/tun.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 782e38b..e26cbea 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1356,6 +1356,8 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv, ret = tun_do_read(tun, tfile, iocb, iv, len, file->f_flags & O_NONBLOCK); ret = min_t(ssize_t, ret, len); + if (ret > 0) + iocb->ki_pos = ret; out: tun_put(tun); return ret; -- 1.7.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] f2fs: add unlikely() macro for compiler more aggressively
This patch adds unlikely() macro into the most of codes.
The basic rule is to add that when:
- checking unusual errors,
- checking page mappings,
- and the other unlikely conditions.
Cc: Chao Yu
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 22 ++
fs/f2fs/data.c | 63 +--
fs/f2fs/dir.c| 10 ++---
fs/f2fs/file.c | 23 +-
fs/f2fs/gc.c | 19 -
fs/f2fs/inode.c | 12 +++---
fs/f2fs/namei.c | 24 ++-
fs/f2fs/node.c | 117 +++
fs/f2fs/recovery.c | 10 ++---
fs/f2fs/segment.c| 42 +-
fs/f2fs/super.c | 83 ++--
fs/f2fs/xattr.c | 28 ++--
12 files changed, 234 insertions(+), 219 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 6b21066..25b67bb 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -34,7 +34,7 @@ struct page *grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t
index)
struct page *page = NULL;
repeat:
page = grab_cache_page(mapping, index);
- if (!page) {
+ if (unlikely(!page)) {
cond_resched();
goto repeat;
}
@@ -54,7 +54,7 @@ struct page *get_meta_page(struct f2fs_sb_info *sbi, pgoff_t
index)
struct page *page;
repeat:
page = grab_cache_page(mapping, index);
- if (!page) {
+ if (unlikely(!page)) {
cond_resched();
goto repeat;
}
@@ -66,7 +66,7 @@ repeat:
goto repeat;
lock_page(page);
- if (page->mapping != mapping) {
+ if (unlikely(page->mapping != mapping)) {
f2fs_put_page(page, 1);
goto repeat;
}
@@ -142,7 +142,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
page_type type,
nr_pages = pagevec_lookup_tag(, mapping, ,
PAGECACHE_TAG_DIRTY,
min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
- if (unlikely(nr_pages == 0))
+ if (nr_pages == 0)
break;
for (i = 0; i < nr_pages; i++) {
@@ -425,7 +425,7 @@ int get_valid_checkpoint(struct f2fs_sb_info *sbi)
unsigned long long cp_start_blk_no;
sbi->ckpt = kzalloc(blk_size, GFP_KERNEL);
- if (!sbi->ckpt)
+ if (unlikely(!sbi->ckpt))
return -ENOMEM;
/*
* Finding out valid cp block involves read both
@@ -473,7 +473,7 @@ static int __add_dirty_inode(struct inode *inode, struct
dir_inode_entry *new)
list_for_each(this, head) {
struct dir_inode_entry *entry;
entry = list_entry(this, struct dir_inode_entry, list);
- if (entry->inode == inode)
+ if (unlikely(entry->inode == inode))
return -EEXIST;
}
list_add_tail(>list, head);
@@ -485,6 +485,7 @@ void set_dirty_dir_page(struct inode *inode, struct page
*page)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct dir_inode_entry *new;
+ int ret;
if (!S_ISDIR(inode->i_mode))
return;
@@ -494,7 +495,8 @@ void set_dirty_dir_page(struct inode *inode, struct page
*page)
INIT_LIST_HEAD(>list);
spin_lock(>dir_inode_lock);
- if (__add_dirty_inode(inode, new))
+ ret = __add_dirty_inode(inode, new);
+ if (unlikely(ret))
kmem_cache_free(inode_entry_slab, new);
inc_page_count(sbi, F2FS_DIRTY_DENTS);
@@ -508,12 +510,14 @@ void add_dirty_dir_inode(struct inode *inode)
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct dir_inode_entry *new =
f2fs_kmem_cache_alloc(inode_entry_slab, GFP_NOFS);
+ int ret;
new->inode = inode;
INIT_LIST_HEAD(>list);
spin_lock(>dir_inode_lock);
- if (__add_dirty_inode(inode, new))
+ ret = __add_dirty_inode(inode, new);
+ if (unlikely(ret))
kmem_cache_free(inode_entry_slab, new);
spin_unlock(>dir_inode_lock);
}
@@ -783,7 +787,7 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, bool
is_umount)
/* Here, we only have one bio having CP pack */
sync_meta_pages(sbi, META_FLUSH, LONG_MAX);
- if (!is_set_ckpt_flags(ckpt, CP_ERROR_FLAG)) {
+ if (unlikely(!is_set_ckpt_flags(ckpt, CP_ERROR_FLAG))) {
clear_prefree_segments(sbi);
F2FS_RESET_SB_DIRT(sbi);
}
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 2ce5a9e..c6d0322 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -49,11 +49,11 @@ static void f2fs_read_end_io(struct bio *bio, int err)
if (--bvec >= bio->bi_io_vec)
prefetchw(>bv_page->flags);
- if (uptodate) {
-
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
(2013/12/05 23:49), Frank Ch. Eigler wrote: > > Hi, Masami - > > masami.hiramatsu.pt wrote: > >> [...] >> For the safeness of kprobes, I have an idea; introduce a whitelist >> for dynamic events. AFAICS, the biggest unstable issue of kprobes >> comes from putting *many* probes on the functions called from tracers. > > Why do you think so? Oh, because I actually hit this problem when enabling kprobe-events on every *ftrace-related* functions(ring buffer, trace filter etc.) It doesn't crash the kernel but it slows down the machine very much. And finally I have to reboot it forcibly. But when I just enables a few probes on those functions, the system has no problem. In this case, almost probes are miss-hit because of recursion, but anyway each miss-hit involves int3/debug interrupts and it increases the processing time of one event handling by ftrace as below. 1. hit a kprobe outside of ftrace 2. kprobe calls event handler 3. the event handler calls ftrace-related functions to reserve buffer, check filter, commit buffer etc. 3-1. each ftrace/ringbuffer function hits a kprobe 3-2. the kprobe detect recursion and just do single-step and return 4. do single stepping 5. return from kprobe Note that all the problem happens inside the event handler. > We have had problems with single kprobes in the > "wrong" spot. The main reason I showed spraying them widely is to get > wide coverage with minimal information/effort, not to suggest that the > number of concurrent probes per se is a problem. (We have had > systemtap scripts probing some areas of the kernel with thousands of > active kprobes, e.g. for statement-by-statement variable-watching > jobs, and these have worked fine.) Ah, sorry for confusion. Agreed. I just tried to explain that kprobes can cause a performance problem under *very specific* operation. So the whitelist is just for keeping people away from it. >> It doesn't crash the kernel but slows down so much, because every >> probes hit many other nested miss-hit probes. > > (kprobes does have code to detect & handle reentrancy.) Right. :) >> This gives us a big performance impact. [...] > > Sure, but I'd expect to see pure slowdowns show their impact with > time-related problems like watchdogs firing or timeouts. I doubt it can cause, because each probe processing time is still small enough to slip through the watchdog. >> [...] Then, I'd like to propose this new whitelist feature in >> kprobe-tracer (not raw kprobe itself). And a sysctl knob for >> disabling the whitelist. That knob will be >> /proc/sys/debug/kprobe-event-whitelist and disabling it will mark >> kernel tainted so that we can check it from bug reports. > > How would one assemble a reliable whitelist, if we haven't fully > characterized the problems that make the blacklist necessary? As I said, we can use function graph tracer's list as the whitelist, since it doesn't include any functions invoked from ftrace's event handler. (Note that I don't mention the Systemtap or other user here) Whitelist is just for keeping the people away from the quantitative issue, who just want to trace their subsystems except for ftrace. For example, such people may try to probe every functions (e.g. perf probe --add '* $vars' : actually this is why I don't release wildcard support on perf probe yet). Of course I can implement the whitelist feature in perf probe only, that will allow me to support wildcard on perf probe. :) For the long term solution, I think we can introduce some kind of performance gatekeeper as systemtap does. Counting the miss-hit rate per second and if it go over a threshold, disable next miss-hit (or most miss-hit) probe (as OOM killer does). Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next PATCH 3/6] macvtap: remove the dead branch
On Fri, Dec 6, 2013 at 2:08 PM, Guenter Roeck wrote: > On 12/05/2013 02:28 PM, Zhi Yong Wu wrote: >> >> From: Zhi Yong Wu >> >> Signed-off-by: Zhi Yong Wu >> --- >> drivers/net/macvtap.c |2 -- >> 1 files changed, 0 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c >> index 9093004..d271fb4 100644 >> --- a/drivers/net/macvtap.c >> +++ b/drivers/net/macvtap.c >> @@ -779,8 +779,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue >> *q, >> return -EINVAL; >> >> ret = macvtap_skb_to_vnet_hdr(skb, _hdr); >> - if (ret) >> - return ret; >> > Assigning the function's return value to ret just to ignore it seems odd. > > Might make sense to change the function type to void. Yes, this is done in the next patch of this series. > > Guenter > -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM : unwinder : Prevent data abort due to stack overflow
While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.
To prevent this problem from happening, execute the instructions that
can cause a data abort in separate helper functions, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
---
arch/arm/kernel/unwind.c | 138 ++-
1 file changed, 100 insertions(+), 38 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..6d854f8 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -49,6 +49,8 @@
#include
#include
+#define TOTAL_REGISTERS 16
+
/* Dummy functions to avoid linker complaints */
void __aeabi_unwind_cpp_pr0(void)
{
@@ -66,9 +68,11 @@ void __aeabi_unwind_cpp_pr2(void)
EXPORT_SYMBOL(__aeabi_unwind_cpp_pr2);
struct unwind_ctrl_block {
- unsigned long vrs[16]; /* virtual register set */
+ unsigned long vrs[TOTAL_REGISTERS]; /* virtual register set */
const unsigned long *insn; /* pointer to the current instructions
word */
+ unsigned long sp_high; /* highest value of sp allowed*/
int entries;/* number of entries left to interpret
*/
+ int last_register_set; /* store if we are at the last set */
int byte; /* current byte number in the
instructions word */
};
@@ -235,12 +239,85 @@ static unsigned long unwind_get_byte(struct
unwind_ctrl_block *ctrl)
return ret;
}
+/* Before poping a register check whether it is feasible or not */
+static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
+ unsigned long **vsp, unsigned int reg)
+{
+ if (unlikely(ctrl->last_register_set))
+ if (*vsp >= (unsigned long *)ctrl->sp_high)
+ return -URC_FAILURE;
+
+ ctrl->vrs[reg] = *(*vsp)++;
+ return URC_OK;
+}
+
+/* Helper functions to execute the instructions */
+static int unwind_exec_pop_subset_r4_to_r13(struct unwind_ctrl_block *ctrl,
+ unsigned long mask)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int load_sp, reg = 4;
+
+ load_sp = mask & (1 << (13 - 4));
+ while (mask) {
+ if (mask & 1)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+ mask >>= 1;
+ reg++;
+ }
+ if (!load_sp)
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ return URC_OK;
+}
+
+static int unwind_exec_pop_r4_to_rN(struct unwind_ctrl_block *ctrl,
+ unsigned long insn)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int reg;
+
+ /* pop R4-R[4+bbb] */
+ for (reg = 4; reg <= 4 + (insn & 7); reg++)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+
+ if (insn & 0x80)
+ if (unwind_pop_register(ctrl, , 14))
+ return -URC_FAILURE;
+
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ return URC_OK;
+}
+
+static int unwind_exec_pop_subset_r0_to_r3(struct unwind_ctrl_block *ctrl,
+ unsigned long mask)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int reg = 0;
+
+ /* pop R0-R3 according to mask */
+ while (mask) {
+ if (mask & 1)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+ mask >>= 1;
+ reg++;
+ }
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ return URC_OK;
+}
+
/*
* Execute the current unwind instruction.
*/
static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
{
unsigned long insn = unwind_get_byte(ctrl);
+ int ret = URC_OK;
pr_debug("%s: insn = %08lx\n", __func__, insn);
@@ -250,8 +327,6 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
ctrl->vrs[SP] -= ((insn & 0x3f) << 2) + 4;
else if ((insn & 0xf0) == 0x80) {
unsigned long mask;
- unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
- int load_sp, reg = 4;
insn = (insn << 8) | unwind_get_byte(ctrl);
mask = insn & 0x0fff;
@@ -261,29 +336,16 @@ static int unwind_exec_insn(struct unwind_ctrl_block
*ctrl)
return -URC_FAILURE;
}
- /* pop R4-R15 according to mask */
- load_sp = mask & (1 << (13 - 4));
- while (mask) {
- if (mask & 1)
- ctrl->vrs[reg] =
Re: [net-next PATCH 3/6] macvtap: remove the dead branch
On 12/05/2013 02:28 PM, Zhi Yong Wu wrote: From: Zhi Yong Wu Signed-off-by: Zhi Yong Wu --- drivers/net/macvtap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 9093004..d271fb4 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -779,8 +779,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q, return -EINVAL; ret = macvtap_skb_to_vnet_hdr(skb, _hdr); - if (ret) - return ret; Assigning the function's return value to ret just to ignore it seems odd. Might make sense to change the function type to void. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: tegra: add pinmux controller to tegra124.dtsi
On Friday 06 December 2013 04:49 AM, Stephen Warren wrote: On 12/05/2013 04:16 PM, Stephen Warren wrote: On 12/05/2013 03:57 AM, Laxman Dewangan wrote: The tegra124 pinmux controller is identical to tegra114 with removing some of existing pins from T114 and adding new pins. I already sent this patch. Oh, I do notice one difference between the two patches: Mine: + reg = <0x7868 0x148>, /* Pad control registers */ + <0x70003000 0x40c>; /* Mux registers */ Yours: + reg = <0x7868 0x164 /* Pad control registers */ + 0x70003000 0x434>;/* PinMux registers */ Are the increase register lengths in your patch correct? If so, I guess I'll drop my patch and replace it with yours if you fix up the unit address. Yes, the last entry of the bank 0 and 1 are: DRV_PINGROUP(ao4, 0x9c8, 2, 3, 4, 12, 7, 20, 7, 28, 2, 30, 2, Y), and PINGROUP(dp_hpd_pff0, DP, RSVD2, RSVD3, RSVD4, DP, 0x3430, N, N, N), -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: TIDSPBRIDGE: Remove UUID helper
Hi Greg, On 01.12.2013 19:07, Ivaylo DImitrov wrote: From: Ivaylo Dimitrov Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't need to be exported. It can also be made way simpler by using sscanf. Signed-off-by: Ivaylo Dimitrov --- drivers/staging/tidspbridge/Makefile |2 +- drivers/staging/tidspbridge/gen/uuidutil.c | 85 .../tidspbridge/include/dspbridge/uuidutil.h | 18 drivers/staging/tidspbridge/rmgr/dbdcd.c | 42 +- 4 files changed, 39 insertions(+), 108 deletions(-) delete mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c I guess the initial mail somehow didn't make it through your spam filter: https://lkml.org/lkml/2013/12/1/70 Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: Do not hardcode perl path
> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, December 06, 2013 1:22 AM > To: Jagannadha Sutradharudu Teki > Cc: linux-kernel@vger.kernel.org; Andy Whitcroft; Jagannadha Sutradharudu > Teki > Subject: Re: [PATCH] checkpatch: Do not hardcode perl path > > On Thu, 2013-12-05 at 16:53 +0530, Jagannadha Sutradharudu Teki wrote: > > checkpatch.pl requires perl v5.10.0 to run but it doesn't require to > > place in /usr/bin/perl Use env to ensure that the interpreter used is > > the first one on environment's $PATH on system with several versions > > of perl installed. > > I don't have an opinion on this patch. fyi: I have some notes here - this change will took the perl bin(if user explicitly use perl instead of from /usr/bin/perl) from bashrc instead of taking /usr/bin/perl all the time. Jagan. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH tip 0/5] tracing filters with BPF
On Fri, Dec 6, 2013 at 9:20 AM, Andi Kleen wrote: > "H. Peter Anvin" writes: >> >> Not to mention that in that case we might as well -- since we need a >> compiler anyway -- generate the machine code in user space; the JIT >> solution really only is useful if it can provide something that we can't >> do otherwise, e.g. enable it in secure boot environments. > > I can see there may be some setups which don't have a compiler > (e.g. I know some people don't use systemtap because of that) > But this needs a custom gcc install too as far as I understand. > If it's depend on gcc, then it's look like Systemtap. There have big inconvenient for embedded environment and many production system to install gcc. (not sure if it need kernel compilation environment as well) It seems the event filter is binding to specific event, it's not possible to trace many events in a cooperation style, look Systemtap and ktap samples, many event handler need to cooperate, the simplest example is record syscall execution time(duration of exit - entry). If this design is intentional, then I would think it's target for speed up current kernel tracing filter.(but need extra usespace filter compiler) And I guess bpf filter still need to take mind on usespace tracing :), if it want to be a complete and integrated tracing solution. (use a separated userspace compiler or translator to resolve symbol) Thanks Jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH tip 0/5] tracing filters with BPF
On Thu, Dec 5, 2013 at 2:38 AM, Ingo Molnar wrote:
>
>> Also I'm thinking to add 'license_string' section to bpf binary format
>> and call license_is_gpl_compatible() on it during load.
>> If false, then just reject it…. not even messing with taint flags...
>> That would be way stronger indication of bpf licensing terms than what
>> we have for .ko
>
> But will BFP tools generate such gpl-compatible license tags by
> default? If yes then this might work, combined with the facility
> below. If not then it's just a nuisance to users.
yes. similar to existing .ko module_license() tag. see below.
> My concern would be solved by adding a facility to always be able to
> dump source code as well, i.e. trivially transform it to C or so, so
> that people can review it - or just edit it on the fly, recompile and
> reinsert? Most BFP scripts ought to be pretty simple.
C code has '#include' in them, so without storing fully preprocessed code
it will not be equivalent. but then true source will be gigantic.
Can be zipped, but that sounds like an overkill.
Also we might want other languages with their own dependent includes.
Sure, we can have a section in bpf binary that has the source, but it's not
enforceable. Kernel cannot know that it's an actual source.
gcc/llvm will produce different bpf code out of the same source.
the source is in C or in language X, etc.
Doesn't seem that including some form of source will help
with enforcing the license.
imo requiring module_license("gpl"); line in C code and equivalent
string in all other languages that want to translate to bpf would be
stronger indication of licensing terms.
then compiler would have to include that string into 'license_string'
section and kernel can actually enforce it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] phy: core: Change the way of_phy_get is called
Hi,
On Thursday 05 December 2013 05:59 PM, Kamil Debski wrote:
> Previously the of_phy_get function took a struct device * and
> was declared static. It was impossible to call it from
> another driver and thus it was impossible to get phy defined
It was never intended to be called from other drivers. What's up with the
wrapper of of_phy_get, phy_get()/devm_phy_get()? Why isn't that enough?
Thanks
Kishon
> for a given node.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> drivers/phy/phy-core.c | 12 +---
> include/linux/phy/phy.h |1 +
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 03cf8fb..7fb3474 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -250,20 +250,17 @@ EXPORT_SYMBOL_GPL(phy_power_off);
> * not yet loaded. This function uses of_xlate call back function provided
> * while registering the phy_provider to find the phy instance.
> */
> -static struct phy *of_phy_get(struct device *dev, int index)
> +struct phy *of_phy_get(struct device_node *np, int index)
> {
> int ret;
> struct phy_provider *phy_provider;
> struct phy *phy = NULL;
> struct of_phandle_args args;
>
> - ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
> + ret = of_parse_phandle_with_args(np, "phys", "#phy-cells",
> index, );
> - if (ret) {
> - dev_dbg(dev, "failed to get phy in %s node\n",
> - dev->of_node->full_name);
> + if (ret)
> return ERR_PTR(-ENODEV);
> - }
>
> mutex_lock(_provider_mutex);
> phy_provider = of_phy_provider_lookup(args.np);
> @@ -281,6 +278,7 @@ err0:
>
> return phy;
> }
> +EXPORT_SYMBOL_GPL(of_phy_get);
>
> /**
> * phy_put() - release the PHY
> @@ -370,7 +368,7 @@ struct phy *phy_get(struct device *dev, const char
> *string)
> if (dev->of_node) {
> index = of_property_match_string(dev->of_node, "phy-names",
> string);
> - phy = of_phy_get(dev, index);
> + phy = of_phy_get(dev->of_node, index);
> if (IS_ERR(phy)) {
> dev_err(dev, "unable to find phy\n");
> return phy;
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 6d72269..169f572 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -131,6 +131,7 @@ struct phy *phy_get(struct device *dev, const char
> *string);
> struct phy *devm_phy_get(struct device *dev, const char *string);
> void phy_put(struct phy *phy);
> void devm_phy_put(struct device *dev, struct phy *phy);
> +struct phy *of_phy_get(struct device_node *np, int index);
> struct phy *of_phy_simple_xlate(struct device *dev,
> struct of_phandle_args *args);
> struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH tip 0/5] tracing filters with BPF
Hi Alexei,
On Thu, Dec 5, 2013 at 12:40 PM, Alexei Starovoitov wrote:
>> On Tue, Dec 3, 2013 at 4:01 PM, Andi Kleen wrote:
>>>
>>> Can you do some performance comparison compared to e.g. ktap?
>>> How much faster is it?
>
> Did simple ktap test with 1M alloc_skb/kfree_skb toy test from earlier email:
> trace skb:kfree_skb {
> if (arg2 == 0x100) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 350315 (usecs)
>
> baseline without any tracing:
> 1M skb alloc/free 145400 (usecs)
>
> then equivalent bpf test:
> void filter(struct bpf_context *ctx)
> {
> void *loc = (void *)ctx->regs.dx;
> if (loc == 0x100) {
> struct sk_buff *skb = (struct sk_buff *)ctx->regs.si;
> char fmt[] = "skb %p loc %p\n";
> bpf_trace_printk(fmt, sizeof(fmt), (long)skb, (long)loc, 0);
> }
> }
> 1M skb alloc/free 183214 (usecs)
>
> so with one 'if' condition the difference ktap vs bpf is 350-145 vs 183-145
>
> obviously ktap is an interpreter, so it's not really fair.
>
> To make it really unfair I did:
> trace skb:kfree_skb {
> if (arg2 == 0x100 || arg2 == 0x200 || arg2 == 0x300 || arg2 == 0x400
> ||
> arg2 == 0x500 || arg2 == 0x600 || arg2 == 0x700 || arg2 == 0x800
> ||
> arg2 == 0x900 || arg2 == 0x1000) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 484280 (usecs)
>
> and corresponding bpf:
> void filter(struct bpf_context *ctx)
> {
> void *loc = (void *)ctx->regs.dx;
> if (loc == 0x100 || loc == 0x200 || loc == 0x300 || loc == 0x400 ||
> loc == 0x500 || loc == 0x600 || loc == 0x700 || loc == 0x800 ||
> loc == 0x900 || loc == 0x1000) {
> struct sk_buff *skb = (struct sk_buff *)ctx->regs.si;
> char fmt[] = "skb %p loc %p\n";
> bpf_trace_printk(fmt, sizeof(fmt), (long)skb, (long)loc, 0);
> }
> }
> 1M skb alloc/free 185660 (usecs)
>
> the difference is bigger now: 484-145 vs 185-145
>
There have big differences for compare arg2(in ktap) with direct register
access(ctx->regs.dx).
The current argument fetching(arg2 in above testcase) implementation in ktap
is very inefficient, see ktap/interpreter/lib_kdebug.c:kp_event_getarg.
The only way to speedup is kernel tracing code change, let external tracing
module access event field not through list lookup. This work is not
started yet. :)
Of course, I'm not saying this argument fetching issue is the performance
root cause compared with bpf and Systemtap, the bytecode executing speed
wouldn't compare with raw machine code.
(There have a plan to use JIT in ktap core, like luajit project, but
it need some
time to work on)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH tip 0/5] tracing filters with BPF
On Thu, Dec 5, 2013 at 5:20 PM, Andi Kleen wrote: >> the difference is bigger now: 484-145 vs 185-145 > > This is a obvious improvement, but imho not big enough to be extremely > compelling (< cost 1-2 cache misses, no orders of magnitude improvements > that would justify a lot of code) hmm. we're comparing against ktap here… which has 5x more kernel code and 8x slower in this test... > Your code requires a compiler, so from my perspective it > wouldn't be a lot easier or faster to use than just changing > the code directly and recompile. > > The users want something simple too that shields them from > having to learn all the internals. They don't want to recompile. > As far as I can tell your code is a bit too low level for that, > and the requirement for the compiler may also scare them. > > Where exactly does it fit? the goal is to have llvm compiler next to perf, wrapped in a user friendly way. compiling small filter vs recompiling full kernel… inserting into live kernel vs rebooting … not sure how you're saying it's equivalent. In my kernel debugging experience current tools (tracing, systemtap) were rarely enough. I always had to add my own printks through the code, recompile and reboot. Often just to see that it's not the place where I want to print things or it's too verbose. Then I would adjust printks, recompile and reboot again. That was slow and tedious, since I would be crashing things from time to time just because skb doesn't always have a valid dev or I made a typo. For debugging I do really need something quick and dirty that lets me add my own printk of whatever structs I want anywhere in the kernel without crashing it. That's exactly what bpf tracing filters do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block: fix memory leaks on unplugging block device
All objects, which are allocated in blk_mq_register_disk, must be
released in blk_mq_unregister_disk.
I use a KVM virtual machine and virtio disk to reproduce this issue.
kmemleak: 18 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
$ cat /sys/kernel/debug/kmemleak | head -n 30
unreferenced object 0x8800b6636150 (size 8):
comm "kworker/0:2", pid 65, jiffies 4294809903 (age 86.358s)
hex dump (first 8 bytes):
76 69 72 74 69 6f 34 00 virtio4.
backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] __kmalloc_track_caller+0xf5/0x260
[] kstrdup+0x31/0x60
[] sysfs_new_dirent+0x2e/0x140
[] create_dir+0x38/0xe0
[] sysfs_create_dir_ns+0x73/0xc0
[] kobject_add_internal+0xc9/0x340
[] kobject_add+0x65/0xb0
[] device_add+0x128/0x660
[] device_register+0x1a/0x20
[] register_virtio_device+0x98/0xe0
[] virtio_pci_probe+0x12e/0x1c0
[] local_pci_probe+0x45/0xa0
[] pci_device_probe+0x121/0x130
[] driver_probe_device+0x87/0x390
[] __device_attach+0x3b/0x40
unreferenced object 0x8800b65aa1d8 (size 144):
Fixes: 320ae51feed5 (blk-mq: new multi-queue block IO queueing mechanism)
Cc: Jens Axboe
Signed-off-by: Andrey Vagin
---
block/blk-mq-sysfs.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
index ba6cf8e..b91ce75 100644
--- a/block/blk-mq-sysfs.c
+++ b/block/blk-mq-sysfs.c
@@ -335,9 +335,22 @@ static struct kobj_type blk_mq_hw_ktype = {
void blk_mq_unregister_disk(struct gendisk *disk)
{
struct request_queue *q = disk->queue;
+ struct blk_mq_hw_ctx *hctx;
+ struct blk_mq_ctx *ctx;
+ int i, j;
+
+ queue_for_each_hw_ctx(q, hctx, i) {
+ hctx_for_each_ctx(hctx, ctx, j) {
+ kobject_del(>kobj);
+ kobject_put(>kobj);
+ }
+ kobject_del(>kobj);
+ kobject_put(>kobj);
+ }
kobject_uevent(>mq_kobj, KOBJ_REMOVE);
kobject_del(>mq_kobj);
+ kobject_put(>mq_kobj);
kobject_put(_to_dev(disk)->kobj);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH tip 0/5] tracing filters with BPF
On Thu, Dec 5, 2013 at 3:37 PM, Steven Rostedt wrote: > On Thu, 5 Dec 2013 14:36:58 -0800 > Alexei Starovoitov wrote: > >> On Thu, Dec 5, 2013 at 5:46 AM, Steven Rostedt wrote: >> > >> > I know that it would be great to have the bpf filter run before >> > recording of the tracepoint, but as that becomes quite awkward for a >> > user interface, because it requires intimate knowledge of the kernel >> > source, this speed up on the filter itself may be worth while to have >> > it happen after the recording of the buffer. When it happens after the >> > record, then the bpf has direct access to the event entry and its >> > fields as described by the trace event format files. >> >> I don't understand that 'awkward' part yet. What do you mean by 'knowledge of >> the kernel'? By accessing pt_regs structure? Something else ? >> Can we try fixing the interface first before compromising on performance? > > Let me ask you this. If you do not have the source of the kernel on > hand, can you use BPF to filter the sched_switch tracepoint on prev pid? > > The current filter interface allows you to filter with just what the > running kernel provides. No need for debug info from the vmlinux or > anything else. Understood and agreed. For the users that are satisfied with amount of info that single trace_event provides (like sched_switch) there is probably little reason to do complex filtering. Either they're fine with all the events or will just filter based on pid only. > I'm fine if it becomes a requirement to have a vmlinux built with > DEBUG_INFO to use BPF and have a tool like perf to translate the > filters. But it that must not replace what the current filters do now. > That is, it can be an add on, but not a replacement. Of course. tracing filters via bpf is an additional tool for kernel debugging. bpf by itself has use cases beyond tracing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net/fddi: Replace local marco with PCI standard macro
From: Yijing Wang Date: Fri, 6 Dec 2013 11:06:28 +0800 > On 2013/12/6 6:06, Maciej W. Rozycki wrote: >> On Thu, 5 Dec 2013, Yijing Wang wrote: >> >>> Replace local marco DFX_BUS_PCI with PCI standard marco >>> dev_is_pci(). >> >> Typos above: marco -> macro > > Sorry for the mistake, David, should i need to resend this patch to fix this > typo error? You have to resubmit all of these conversions again because you posted them before the net-next tree was even open for submissions. So you might as well fix the typos etc. while doing so. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/mm/numa: fix becoming single node on numa machine with 32-bit kernel.
On numa machine, if a 32-bit kernel runs over it, node data cannot
be allocated from local node if the account of memory for node 0
covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from other
nodes if the memory of local node is still not mapped. The expected
result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang
---
arch/x86/mm/numa.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err("Cannot find %zu bytes in node %d\n",
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
--
1.7.8.110.g4cb5d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next PATCHv2 0/8] net: some cleanups
From: Zhi Yong Wu Date: Fri, 6 Dec 2013 10:24:01 +0800 > Since net-next is open now, it's time to post them out again. Patches 5 and 7 are bug fixes, and should be submitted to 'net' not 'net-next'. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH 2/5 V2] f2fs: add unlikely() macro for compiler optimization
Hi,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Friday, December 06, 2013 12:12 PM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net; 谭姝
> Subject: Re: [f2fs-dev] [PATCH 2/5 V2] f2fs: add unlikely() macro for
> compiler optimization
>
> Hi,
>
> Just in case, if you agreed the following comments, I'll fix those and
> merge the patch by myself.
> Thanks,
Agreed, thanks.
>
> 2013-12-05 (목), 17:15 +0800, Chao Yu:
> > As we know, some of our branch condition will rarely be true. So we could
> > add
> > 'unlikely' to let compiler optimize these code, by this way we could drop
> > unneeded 'jump' assemble code to improve performance.
> >
> > change log:
> > o add *unlikely* as many as possible across the whole source files at once
> >suggested by Jaegeuk Kim.
> >
> > Suggested-by: Jaegeuk Kim
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/checkpoint.c | 10 +-
> > fs/f2fs/data.c |4 ++--
> > fs/f2fs/dir.c|4 ++--
> > fs/f2fs/f2fs.h |8
> > fs/f2fs/node.c | 16
> > fs/f2fs/segment.h|2 +-
> > 6 files changed, 22 insertions(+), 22 deletions(-)
> >
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index 38f4a224..6580808 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -82,8 +82,8 @@ static int f2fs_write_meta_page(struct page *page,
> > struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> >
> > /* Should not write any meta pages, if any IO error was occurred */
> > - if (wbc->for_reclaim || sbi->por_doing ||
> > - is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)) {
> > + if (unlikely(wbc->for_reclaim || sbi->por_doing ||
> > + is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG))) {
>
> if (unlikely(sbi->por_doing || is_set_ckpt_flags(F2FS_CKPT(sbi),
> CP_ERROR_FLAG)))
> goto redirty_out;
> if (wbc->for_reclaim)
> goto redirty_out;
>
> redirty_out:
> > dec_page_count(sbi, F2FS_DIRTY_META);
> > wbc->pages_skipped++;
> > set_page_dirty(page);
> > @@ -137,7 +137,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
> > page_type type,
> > nr_pages = pagevec_lookup_tag(, mapping, ,
> > PAGECACHE_TAG_DIRTY,
> > min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
> > - if (nr_pages == 0)
> > + if (unlikely(nr_pages == 0))
> > break;
> >
> > for (i = 0; i < nr_pages; i++) {
> > @@ -150,7 +150,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
> > page_type type,
> > unlock_page(page);
> > break;
> > }
> > - if (nwritten++ >= nr_to_write)
> > + if (unlikely(nwritten++ >= nr_to_write))
>
> nwritten++;
>
> if (unlikely(nwritten >= nr_to_write))
>
>
> > break;
> > }
> > pagevec_release();
> > @@ -200,7 +200,7 @@ int acquire_orphan_inode(struct f2fs_sb_info *sbi)
> > max_orphans = (sbi->blocks_per_seg - 2 - NR_CURSEG_TYPE)
> > * F2FS_ORPHANS_PER_BLOCK;
> > mutex_lock(>orphan_inode_mutex);
> > - if (sbi->n_orphans >= max_orphans)
> > + if (unlikely(sbi->n_orphans >= max_orphans))
> > err = -ENOSPC;
> > else
> > sbi->n_orphans++;
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 4e2fc09..2ce5a9e 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -251,7 +251,7 @@ int reserve_new_block(struct dnode_of_data *dn)
> >
> > if (is_inode_flag_set(F2FS_I(dn->inode), FI_NO_ALLOC))
> > return -EPERM;
> > - if (!inc_valid_block_count(sbi, dn->inode, 1))
> > + if (unlikely(!inc_valid_block_count(sbi, dn->inode, 1)))
> > return -ENOSPC;
> >
> > trace_f2fs_reserve_new_block(dn->inode, dn->nid, dn->ofs_in_node);
> > @@ -711,7 +711,7 @@ static int f2fs_write_data_page(struct page *page,
> >
> > zero_user_segment(page, offset, PAGE_CACHE_SIZE);
> > write:
> > - if (sbi->por_doing) {
> > + if (unlikely(sbi->por_doing)) {
> > err = AOP_WRITEPAGE_ACTIVATE;
> > goto redirty_out;
> > }
> > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > index 594fc1b..0cc26ba 100644
> > --- a/fs/f2fs/dir.c
> > +++ b/fs/f2fs/dir.c
> > @@ -190,7 +190,7 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode
> > *dir,
> > unsigned int max_depth;
> > unsigned int level;
> >
> > - if (namelen > F2FS_NAME_LEN)
> > + if (unlikely(namelen > F2FS_NAME_LEN))
> > return NULL;
> >
> > if (npages == 0)
> > @@ -461,7 +461,7 @@ int __f2fs_add_link(struct inode *dir, const struct
> > qstr *name, struct inode *in
> > }
> >
> >
[GIT PULL] DeviceTree fixes for 3.13
Linus, Please pull. Just some binding documentation updates and DT maintainers updates. Rob The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/dt-fixes-for-3.13 for you to fetch changes up to 2c0e641a963d073d60cb63c24614c642b6f64b21: dt: binding: reword PowerPC 8xxx GPIO documentation (2013-12-03 00:01:03 -0600) - Various DT binding documentation updates. - Add Kumar Gala and remove Stephen Warren as DT binding maintainers. Chanwoo Choi (1): hwmon: ntc_thermistor: Fix typo (pullup-uV -> pullup-uv) Fabio Estevam (1): Documentation: net: fsl-fec.txt: Add phy-supply entry Gerhard Sittig (1): dt: binding: reword PowerPC 8xxx GPIO documentation Kumar Gala (1): MAINTAINERS: Add Kumar to Device Tree Binding maintainers group Laurent Pinchart (1): clk: exynos: Fix typos in DT bindings documentation Rob Herring (1): dt-bindings: add ARMv8 PMU binding Sricharan R (1): ARM: dts: doc: Document missing binding for omap5-mpu Stephen Warren (2): MAINTAINERS: remove swarren from DT bindings ARM: tegra: delete nvidia,tegra20-spi.txt binding Thierry Reding (1): of: Add vendor prefix for LG Corporation Wei Ni (1): of: add vendor prefix for GMT Documentation/devicetree/bindings/arm/omap/mpu.txt | 8 +++ Documentation/devicetree/bindings/arm/pmu.txt | 1 + .../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +- .../devicetree/bindings/clock/exynos4-clock.txt| 2 +- .../devicetree/bindings/clock/exynos5250-clock.txt | 2 +- .../devicetree/bindings/clock/exynos5420-clock.txt | 2 +- .../devicetree/bindings/clock/exynos5440-clock.txt | 2 +- .../devicetree/bindings/gpio/8xxx_gpio.txt | 66 +- Documentation/devicetree/bindings/net/fsl-fec.txt | 2 + .../devicetree/bindings/spi/nvidia,tegra20-spi.txt | 5 -- .../devicetree/bindings/vendor-prefixes.txt| 2 + MAINTAINERS| 2 +- 12 files changed, 59 insertions(+), 37 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/nvidia,tegra20-spi.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, December 06, 2013 5:31 AM
> To: Bhushan Bharat-R65777
> Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart-
> B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
>
> On Sun, 2013-11-24 at 23:33 -0600, Bharat Bhushan wrote:
> >
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Friday, November 22, 2013 2:31 AM
> > > To: Wood Scott-B07421
> > > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de;
> > > Yoder Stuart-B08248; io...@lists.linux-foundation.org;
> > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > IOMMU (PAMU)
> > >
> > > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> > > > On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote:
> > > > > On Thu, 2013-11-21 at 11:20 +, Bharat Bhushan wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > > > > Sent: Thursday, November 21, 2013 12:17 AM
> > > > > > > To: Bhushan Bharat-R65777
> > > > > > > Cc: j...@8bytes.org; bhelg...@google.com; ag...@suse.de;
> > > > > > > Wood Scott-B07421; Yoder Stuart-B08248;
> > > > > > > io...@lists.linux-foundation.org; linux-
> > > > > > > p...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> > > > > > > ker...@vger.kernel.org; Bhushan Bharat-R65777
> > > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for
> > > > > > > Freescale IOMMU (PAMU)
> > > > > > >
> > > > > > > Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie. each
> > > > > > > vfio user has $COUNT regions at their disposal exclusively)?
> > > > > >
> > > > > > Number of msi-bank count is system wide and not per aperture,
> > > > > > But will be
> > > setting windows for banks in the device aperture.
> > > > > > So say if we are direct assigning 2 pci device (both have
> > > > > > different iommu
> > > group, so 2 aperture in iommu) to VM.
> > > > > > Now qemu can make only one call to know how many msi-banks are
> > > > > > there but
> > > it must set sub-windows for all banks for both pci device in its
> > > respective aperture.
> > > > >
> > > > > I'm still confused. What I want to make sure of is that the
> > > > > banks are independent per aperture. For instance, if we have
> > > > > two separate userspace processes operating independently and
> > > > > they both chose to use msi bank zero for their device, that's
> > > > > bank zero within each aperture and doesn't interfere. Or
> > > > > another way to ask is can a malicious user interfere with other users
> > > > > by
> using the wrong bank.
> > > > > Thanks,
> > > >
> > > > They can interfere.
> >
> > Want to be sure of how they can interfere?
>
> If more than one VFIO user shares the same MSI group, one of the users can
> send
> MSIs to another user, by using the wrong interrupt within the bank.
> Unexpected
> MSIs could cause misbehavior or denial of service.
>
> > >> With this hardware, the only way to prevent that
> > > > is to make sure that a bank is not shared by multiple protection
> > > > contexts.
> > > > For some of our users, though, I believe preventing this is less
> > > > important than the performance benefit.
> >
> > So should we let this patch series in without protection?
>
> No, there should be some sort of opt-in mechanism similar to IOMMU-less VFIO
> --
> but not the same exact one, since one is a much more serious loss of isolation
> than the other.
Can you please elaborate "opt-in mechanism"?
>
> > > I think we need some sort of ownership model around the msi banks then.
> > > Otherwise there's nothing preventing another userspace from
> > > attempting an MSI based attack on other users, or perhaps even on
> > > the host. VFIO can't allow that. Thanks,
> >
> > We have very few (3 MSI bank on most of chips), so we can not assign
> > one to each userspace.
>
> That depends on how many users there are.
What I think we can do is:
- Reserve one MSI region for host. Host will not share MSI region with Guest.
- For upto 2 Guest (MAX msi with host - 1) give then separate MSI sub regions
- Additional Guest will share MSI region with other guest.
Any better suggestion are most welcome.
Thanks
-Bharat
>
> -Scott
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, December 06, 2013 5:52 AM > To: Bhushan Bharat-R65777 > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de; Yoder Stuart- > B08248; io...@lists.linux-foundation.org; bhelg...@google.com; linuxppc- > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU) > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote: > > > > > -Original Message- > > > From: Bhushan Bharat-R65777 > > > Sent: Wednesday, November 27, 2013 9:39 PM > > > To: 'Alex Williamson' > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; ag...@suse.de; > > > Yoder Stuart- B08248; io...@lists.linux-foundation.org; > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org; > > > linux-kernel@vger.kernel.org > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > IOMMU (PAMU) > > > > > > > > > > > > > -Original Message- > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > Sent: Monday, November 25, 2013 10:08 PM > > > > To: Bhushan Bharat-R65777 > > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; ag...@suse.de; > > > > Yoder > > > > Stuart- B08248; io...@lists.linux-foundation.org; > > > > bhelg...@google.com; > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale > > > > IOMMU > > > > (PAMU) > > > > > > > > On Mon, 2013-11-25 at 05:33 +, Bharat Bhushan wrote: > > > > > > > > > > > -Original Message- > > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > > > Sent: Friday, November 22, 2013 2:31 AM > > > > > > To: Wood Scott-B07421 > > > > > > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; > > > > > > ag...@suse.de; Yoder Stuart-B08248; > > > > > > io...@lists.linux-foundation.org; bhelg...@google.com; > > > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org > > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for > > > > > > Freescale IOMMU (PAMU) > > > > > > > > > > > > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote: > > > > > > > On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote: > > > > > > > > On Thu, 2013-11-21 at 11:20 +, Bharat Bhushan wrote: > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > From: Alex Williamson > > > > > > > > > > [mailto:alex.william...@redhat.com] > > > > > > > > > > Sent: Thursday, November 21, 2013 12:17 AM > > > > > > > > > > To: Bhushan Bharat-R65777 > > > > > > > > > > Cc: j...@8bytes.org; bhelg...@google.com; > > > > > > > > > > ag...@suse.de; Wood Scott-B07421; Yoder Stuart-B08248; > > > > > > > > > > io...@lists.linux-foundation.org; linux- > > > > > > > > > > p...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > > > > > > linux- ker...@vger.kernel.org; Bhushan Bharat-R65777 > > > > > > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for > > > > > > > > > > Freescale IOMMU (PAMU) > > > > > > > > > > > > > > > > > > > > Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie. > > > > > > > > > > each vfio user has $COUNT regions at their disposal > exclusively)? > > > > > > > > > > > > > > > > > > Number of msi-bank count is system wide and not per > > > > > > > > > aperture, But will be > > > > > > setting windows for banks in the device aperture. > > > > > > > > > So say if we are direct assigning 2 pci device (both > > > > > > > > > have different iommu > > > > > > group, so 2 aperture in iommu) to VM. > > > > > > > > > Now qemu can make only one call to know how many > > > > > > > > > msi-banks are there but > > > > > > it must set sub-windows for all banks for both pci device in > > > > > > its respective aperture. > > > > > > > > > > > > > > > > I'm still confused. What I want to make sure of is that > > > > > > > > the banks are independent per aperture. For instance, if > > > > > > > > we have two separate userspace processes operating > > > > > > > > independently and they both chose to use msi bank zero for > > > > > > > > their device, that's bank zero within each aperture and > > > > > > > > doesn't interfere. Or another way to ask is can a > > > > > > > > malicious user interfere with other users by > > > > using the wrong bank. > > > > > > > > Thanks, > > > > > > > > > > > > > > They can interfere. > > > > > > > > > > Want to be sure of how they can interfere? > > > > > > > > What happens if more than one user selects the same MSI bank? > > > > Minimally, wouldn't that result in the IOMMU blocking transactions > > > > from the previous user once the new user activates their mapping? > > > > > > Yes and no; With current implementation yes but with a minor change > > > no. Later in this response I will explain how. > > > > > > > > > > > > >> With this hardware, the only way to prevent that > > > > > > > is to make sure that a bank is not shared by
Re: [f2fs-dev] [PATCH 2/5 V2] f2fs: add unlikely() macro for compiler optimization
Hi,
Just in case, if you agreed the following comments, I'll fix those and
merge the patch by myself.
Thanks,
2013-12-05 (목), 17:15 +0800, Chao Yu:
> As we know, some of our branch condition will rarely be true. So we could add
> 'unlikely' to let compiler optimize these code, by this way we could drop
> unneeded 'jump' assemble code to improve performance.
>
> change log:
> o add *unlikely* as many as possible across the whole source files at once
>suggested by Jaegeuk Kim.
>
> Suggested-by: Jaegeuk Kim
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/checkpoint.c | 10 +-
> fs/f2fs/data.c |4 ++--
> fs/f2fs/dir.c|4 ++--
> fs/f2fs/f2fs.h |8
> fs/f2fs/node.c | 16
> fs/f2fs/segment.h|2 +-
> 6 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 38f4a224..6580808 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -82,8 +82,8 @@ static int f2fs_write_meta_page(struct page *page,
> struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
>
> /* Should not write any meta pages, if any IO error was occurred */
> - if (wbc->for_reclaim || sbi->por_doing ||
> - is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)) {
> + if (unlikely(wbc->for_reclaim || sbi->por_doing ||
> + is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG))) {
if (unlikely(sbi->por_doing || is_set_ckpt_flags(F2FS_CKPT(sbi),
CP_ERROR_FLAG)))
goto redirty_out;
if (wbc->for_reclaim)
goto redirty_out;
redirty_out:
> dec_page_count(sbi, F2FS_DIRTY_META);
> wbc->pages_skipped++;
> set_page_dirty(page);
> @@ -137,7 +137,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
> page_type type,
> nr_pages = pagevec_lookup_tag(, mapping, ,
> PAGECACHE_TAG_DIRTY,
> min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
> - if (nr_pages == 0)
> + if (unlikely(nr_pages == 0))
> break;
>
> for (i = 0; i < nr_pages; i++) {
> @@ -150,7 +150,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
> page_type type,
> unlock_page(page);
> break;
> }
> - if (nwritten++ >= nr_to_write)
> + if (unlikely(nwritten++ >= nr_to_write))
nwritten++;
if (unlikely(nwritten >= nr_to_write))
> break;
> }
> pagevec_release();
> @@ -200,7 +200,7 @@ int acquire_orphan_inode(struct f2fs_sb_info *sbi)
> max_orphans = (sbi->blocks_per_seg - 2 - NR_CURSEG_TYPE)
> * F2FS_ORPHANS_PER_BLOCK;
> mutex_lock(>orphan_inode_mutex);
> - if (sbi->n_orphans >= max_orphans)
> + if (unlikely(sbi->n_orphans >= max_orphans))
> err = -ENOSPC;
> else
> sbi->n_orphans++;
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 4e2fc09..2ce5a9e 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -251,7 +251,7 @@ int reserve_new_block(struct dnode_of_data *dn)
>
> if (is_inode_flag_set(F2FS_I(dn->inode), FI_NO_ALLOC))
> return -EPERM;
> - if (!inc_valid_block_count(sbi, dn->inode, 1))
> + if (unlikely(!inc_valid_block_count(sbi, dn->inode, 1)))
> return -ENOSPC;
>
> trace_f2fs_reserve_new_block(dn->inode, dn->nid, dn->ofs_in_node);
> @@ -711,7 +711,7 @@ static int f2fs_write_data_page(struct page *page,
>
> zero_user_segment(page, offset, PAGE_CACHE_SIZE);
> write:
> - if (sbi->por_doing) {
> + if (unlikely(sbi->por_doing)) {
> err = AOP_WRITEPAGE_ACTIVATE;
> goto redirty_out;
> }
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index 594fc1b..0cc26ba 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -190,7 +190,7 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
> unsigned int max_depth;
> unsigned int level;
>
> - if (namelen > F2FS_NAME_LEN)
> + if (unlikely(namelen > F2FS_NAME_LEN))
> return NULL;
>
> if (npages == 0)
> @@ -461,7 +461,7 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
> *name, struct inode *in
> }
>
> start:
> - if (current_depth == MAX_DIR_HASH_DEPTH)
> + if (unlikely(current_depth == MAX_DIR_HASH_DEPTH))
> return -ENOSPC;
>
> /* Increase the depth, if required */
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 10eca02..dca18b3 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -574,7 +574,7 @@ static inline void f2fs_unlock_all(struct f2fs_sb_info
> *sbi)
> static inline int check_nid_range(struct f2fs_sb_info *sbi, nid_t nid)
> {
>
[PATCH] Usb: atm: usbatm: fixed a pointer variable format issue
Fixed a pointer variable format issue.
Signed-off-by: Seth Archer Brown
---
drivers/usb/atm/usbatm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 25a7bfc..dada014 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -170,9 +170,9 @@ struct usbatm_control {
static void usbatm_atm_dev_close(struct atm_dev *atm_dev);
static int usbatm_atm_open(struct atm_vcc *vcc);
static void usbatm_atm_close(struct atm_vcc *vcc);
-static int usbatm_atm_ioctl(struct atm_dev *atm_dev, unsigned int cmd, void
__user * arg);
+static int usbatm_atm_ioctl(struct atm_dev *atm_dev, unsigned int cmd, void
__user *arg);
static int usbatm_atm_send(struct atm_vcc *vcc, struct sk_buff *skb);
-static int usbatm_atm_proc_read(struct atm_dev *atm_dev, loff_t * pos, char
*page);
+static int usbatm_atm_proc_read(struct atm_dev *atm_dev, loff_t *pos, char
*page);
static struct atmdev_ops usbatm_atm_devops = {
.dev_close = usbatm_atm_dev_close,
@@ -739,7 +739,7 @@ static void usbatm_atm_dev_close(struct atm_dev *atm_dev)
usbatm_put_instance(instance); /* taken in usbatm_atm_init */
}
-static int usbatm_atm_proc_read(struct atm_dev *atm_dev, loff_t * pos, char
*page)
+static int usbatm_atm_proc_read(struct atm_dev *atm_dev, loff_t *pos, char
*page)
{
struct usbatm_data *instance = atm_dev->dev_data;
int left = *pos;
@@ -895,7 +895,7 @@ static void usbatm_atm_close(struct atm_vcc *vcc)
}
static int usbatm_atm_ioctl(struct atm_dev *atm_dev, unsigned int cmd,
- void __user * arg)
+ void __user *arg)
{
struct usbatm_data *instance = atm_dev->dev_data;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 6
Hi all, Changes since 20131205: The crypto tree gained a build failure so I used the version from next-20131205. Non-merge commits (relative to Linus' tree): 2639 2875 files changed, 111902 insertions(+), 72577 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (29be6345bbae Merge tag 'nfs-for-3.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs) Merging fixes/master (8ae516aa8b81 Merge tag 'trace-fixes-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (da990a4f2d5a ARC: [perf] Fix a few thinkos) Merging arm-current/fixes (11d4bb1bd067 ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (721cb59e9d95 powerpc/windfarm: Fix XServe G5 fan control Makefile issue) Merging sparc/master (1de425c7b271 sparc64: Fix build regression) Merging net/master (e1ca87bb1b64 Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless) Merging ipsec/master (dff345c5c85d be2net: call napi_disable() for all event queues) Merging sound-current/for-linus (18e4753ff3c8 ALSA: usb-audio: fix uninitialized variable compile warning) Merging pci-current/for-linus (4bff6749905d PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev()) Merging wireless/master (a59b40b30f3f Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (dc1ccc48159d Linux 3.13-rc2) Merging tty.current/tty-linus (39434abd942c n_tty: Fix missing newline echo) Merging usb.current/usb-linus (2d51f3cd11f4 usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED) Merging staging.current/staging-linus (55ef003e4ae6 Merge tag 'iio-fixes-for-3.13b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (76a9635979e5 mei: add 9 series PCH mei device ids) Merging input-current/for-linus (95f75e91588a Input: ALPS - add support for DualPoint device on Dell XT2 model) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (8ec25c512916 crypto: testmgr - fix sglen in test_aead for case 'dst != src') Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: add initialization code for dma reserved memory") Merging rr-fixes/fixes (3459f11a8b16 virtio_balloon: update_balloon_size(): update correct field) Merging mfd-fixes/master (88ec6a4d8369 Merge tag 'mfd
[PATCH v2] usb: core: Make sure usb_set_configuration(-1) cannot fail
usb_deauthorize_device() tries to unset the configuration of a USB
device and then unconditionally blows away the configuration descriptors
with usb_destroy_configuration(). This is bad if the
usb_set_configuration() call failed before the configuration could be
correctly unset, since pointers like udev->actconfig can keep pointing
to the now invalid memory. We have encountered hard to reproduce crashes
from devices disconnected during suspend due to this, where khubd's
disconnect handling races with userspace tools that change authorization
on resume.
It seems desirable that a USB device can always be marked as
unconfigured (reclaiming its bandwidth) in the kernel, regardless of
communication problems. This patch changes usb_set_configuration() to
ignore all failures in the case where no new configuration is being set.
Signed-off-by: Julius Werner
---
drivers/usb/core/message.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index bb31597..f980b6d 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1706,7 +1706,8 @@ static void __usb_queue_reset_device(struct work_struct
*ws)
* underlying call that failed. On successful completion, each interface
* in the original device configuration has been destroyed, and each one
* in the new configuration has been probed by all relevant usb device
- * drivers currently known to the kernel.
+ * drivers currently known to the kernel. Guaranteed not to fail if the
+ * device is to be unconfigured (@configuration = -1).
*/
int usb_set_configuration(struct usb_device *dev, int configuration)
{
@@ -1774,7 +1775,7 @@ free_interfaces:
/* Wake up the device so we can send it the Set-Config request */
ret = usb_autoresume_device(dev);
- if (ret)
+ if (ret && cp)
goto free_interfaces;
/* if it's already configured, clear out old state first.
@@ -1797,7 +1798,7 @@ free_interfaces:
* installed, so that the xHCI driver can recalculate the U1/U2
* timeouts.
*/
- if (dev->actconfig && usb_disable_lpm(dev)) {
+ if (dev->actconfig && usb_disable_lpm(dev) && cp) {
dev_err(>dev, "%s Failed to disable LPM\n.", __func__);
mutex_unlock(hcd->bandwidth_mutex);
ret = -ENOMEM;
--
1.7.12.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 02/20] iommu/vt-d: fix PCI device reference leakage on error recovery path
Function dmar_parse_dev_scope() should release the PCI device reference
count gained in function dmar_parse_one_dev_scope() on error recovery,
otherwise will cause PCI device object leakage.
This patch also introduces dmar_free_dev_scope(), which will be used
to support DMAR device hotplug.
Reviewed-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c | 14 --
include/linux/dmar.h |1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 8b452c9..c17dbf7 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -100,7 +100,6 @@ static int __init dmar_parse_one_dev_scope(struct
acpi_dmar_device_scope *scope,
if (!pdev) {
pr_warn("Device scope device [%04x:%02x:%02x.%02x] not found\n",
segment, scope->bus, path->device, path->function);
- *dev = NULL;
return 0;
}
if ((scope->entry_type == ACPI_DMAR_SCOPE_TYPE_ENDPOINT && \
@@ -151,7 +150,7 @@ int __init dmar_parse_dev_scope(void *start, void *end, int
*cnt,
ret = dmar_parse_one_dev_scope(scope,
&(*devices)[index], segment);
if (ret) {
- kfree(*devices);
+ dmar_free_dev_scope(devices, cnt);
return ret;
}
index ++;
@@ -162,6 +161,17 @@ int __init dmar_parse_dev_scope(void *start, void *end,
int *cnt,
return 0;
}
+void dmar_free_dev_scope(struct pci_dev ***devices, int *cnt)
+{
+ if (*devices && *cnt) {
+ while (--*cnt >= 0)
+ pci_dev_put((*devices)[*cnt]);
+ kfree(*devices);
+ *devices = NULL;
+ *cnt = 0;
+ }
+}
+
/**
* dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition
* structure which uniquely represent one DMA remapping hardware unit
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index b029d1a..8adfce0 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -159,6 +159,7 @@ extern int dmar_parse_one_rmrr(struct acpi_dmar_header
*header);
extern int dmar_parse_one_atsr(struct acpi_dmar_header *header);
extern int dmar_parse_dev_scope(void *start, void *end, int *cnt,
struct pci_dev ***devices, u16 segment);
+extern void dmar_free_dev_scope(struct pci_dev ***devices, int *cnt);
extern int intel_iommu_init(void);
#else /* !CONFIG_INTEL_IOMMU: */
static inline int intel_iommu_init(void) { return -ENODEV; }
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 00/20] Bugfixes and improvements for Intel IOMMU drivers
This patchset includes several bugfixes and code improvements for Intel DMA remapping and interrupt remapping drivers. It's also a preparation for Intel IOMMU device hotplug. It applies to the latest mainstream kernel on top of commit 7e3528c3660a2e8602abc7858b0994d611f74bc3 It has been tested on Intel SandyBridge and Romley-4S platforms. Thanks! V2->V3: 1) Add three more patches 18, 19, 20 2) Fix minor bugs in previous version V1->V2: 1) drop one wrong bugfix of " fix remapping interrupt handle leakage in error recovery path" 2) Kill redundant call of bitmap_allocate_region(). 3) Add two new bugfixes. Jiang Liu (20): iommu/vt-d: use dedicated bitmap to track remapping entry allocation status iommu/vt-d: fix PCI device reference leakage on error recovery path iommu/vt-d: fix a race window in allocating domain ID for virtual machines iommu/vt-d: fix resource leakage on error recovery path in iommu_init_domains() iommu/vt-d, trivial: refine support of 64bit guest address iommu/vt-d, trivial: print correct domain id of static identity domain iommu/vt-d, trivial: check suitable flag in function detect_intel_iommu() iommu/vt-d, trivial: clean up unused code iommu/vt-d: mark internal functions as static iommu/vt-d, trivial: use defined macro instead of hardcoding iommu/vt-d, trivial: simplify code with existing macros iommu/vt-d: fix invalid memory access when freeing DMAR irq iommu/vt-d: keep shared resources when failed to initialize iommu devices iommu/vt-d: avoid double free in error recovery path iommu/vt-d: fix access after free issue in function free_dmar_iommu() iommu/vt-d: release invalidation queue when destroying IOMMU unit iommu/vt-d: fix wrong return value of dmar_table_init() iommu/vt-d, PCI, trivial: use dev_is_pci() instead of hardcoding iommu/vt-d, trivial: clean sparse warnings iommu/vt-d: free all resources if failed to initialize DMARs drivers/iommu/dmar.c| 126 drivers/iommu/intel-iommu.c | 220 +-- drivers/iommu/intel_irq_remapping.c | 92 +++ drivers/iommu/irq_remapping.c |6 +- include/linux/dma_remapping.h |4 - include/linux/dmar.h| 17 +-- include/linux/intel-iommu.h |3 +- 7 files changed, 213 insertions(+), 255 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 01/20] iommu/vt-d: use dedicated bitmap to track remapping entry allocation status
Currently Intel interrupt remapping drivers uses the "present" flag bit
in remapping entry to track whether an entry is allocated or not.
It works as follow:
1) allocate a remapping entry and set its "present" flag bit to 1
2) compose other fields for the entry
3) update the remapping entry with the composed value
The remapping hardware may access the entry between step 1 and step 3,
which then obervers an entry with the "present" flag set but random
values in all other fields.
This patch introduces a dedicated bitmap to track remapping entry
allocation status instead of sharing the "present" flag with hardware,
thus eliminate the race window. It also simplifies the implementation.
Tested-and-reviewed-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c | 51 +--
include/linux/intel-iommu.h |1 +
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index bab10b1..282d392 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -72,7 +72,6 @@ static int alloc_irte(struct intel_iommu *iommu, int irq, u16
count)
u16 index, start_index;
unsigned int mask = 0;
unsigned long flags;
- int i;
if (!count || !irq_iommu)
return -1;
@@ -96,32 +95,17 @@ static int alloc_irte(struct intel_iommu *iommu, int irq,
u16 count)
}
raw_spin_lock_irqsave(_2_ir_lock, flags);
- do {
- for (i = index; i < index + count; i++)
- if (table->base[i].present)
- break;
- /* empty index found */
- if (i == index + count)
- break;
-
- index = (index + count) % INTR_REMAP_TABLE_ENTRIES;
-
- if (index == start_index) {
- raw_spin_unlock_irqrestore(_2_ir_lock, flags);
- printk(KERN_ERR "can't allocate an IRTE\n");
- return -1;
- }
- } while (1);
-
- for (i = index; i < index + count; i++)
- table->base[i].present = 1;
-
- cfg->remapped = 1;
- irq_iommu->iommu = iommu;
- irq_iommu->irte_index = index;
- irq_iommu->sub_handle = 0;
- irq_iommu->irte_mask = mask;
-
+ index = bitmap_find_free_region(table->bitmap,
+ INTR_REMAP_TABLE_ENTRIES, mask);
+ if (index < 0) {
+ printk(KERN_ERR "can't allocate an IRTE\n");
+ } else {
+ cfg->remapped = 1;
+ irq_iommu->iommu = iommu;
+ irq_iommu->irte_index = index;
+ irq_iommu->sub_handle = 0;
+ irq_iommu->irte_mask = mask;
+ }
raw_spin_unlock_irqrestore(_2_ir_lock, flags);
return index;
@@ -254,6 +238,8 @@ static int clear_entries(struct irq_2_iommu *irq_iommu)
set_64bit(>low, 0);
set_64bit(>high, 0);
}
+ bitmap_release_region(iommu->ir_table->bitmap, index,
+ irq_iommu->irte_mask);
return qi_flush_iec(iommu, index, irq_iommu->irte_mask);
}
@@ -453,6 +439,7 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu, int mode)
{
struct ir_table *ir_table;
struct page *pages;
+ unsigned long *bitmap;
ir_table = iommu->ir_table = kzalloc(sizeof(struct ir_table),
GFP_ATOMIC);
@@ -470,7 +457,17 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu, int mode)
return -ENOMEM;
}
+ bitmap = kcalloc(BITS_TO_LONGS(INTR_REMAP_TABLE_ENTRIES),
+sizeof(long), GFP_ATOMIC);
+ if (bitmap == NULL) {
+ printk(KERN_ERR "failed to allocate bitmap\n");
+ __free_pages(pages, INTR_REMAP_PAGE_ORDER);
+ kfree(ir_table);
+ return -ENOMEM;
+ }
+
ir_table->base = page_address(pages);
+ ir_table->bitmap = bitmap;
iommu_set_irq_remapping(iommu, mode);
return 0;
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index d380c5e..de1e5e9 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -288,6 +288,7 @@ struct q_inval {
struct ir_table {
struct irte *base;
+ unsigned long *bitmap;
};
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 03/20] iommu/vt-d: fix a race window in allocating domain ID for virtual machines
Function intel_iommu_domain_init() may be concurrently called by upper
layer without serialization, so use atomic_t to protect domain id
allocation.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 43b9bfe..b8e3b48 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3877,7 +3877,7 @@ static void vm_domain_remove_all_dev_info(struct
dmar_domain *domain)
}
/* domain id for virtual machine, it won't be set in context */
-static unsigned long vm_domid;
+static atomic_t vm_domid = ATOMIC_INIT(0);
static struct dmar_domain *iommu_alloc_vm_domain(void)
{
@@ -3887,7 +3887,7 @@ static struct dmar_domain *iommu_alloc_vm_domain(void)
if (!domain)
return NULL;
- domain->id = vm_domid++;
+ domain->id = atomic_inc_return(_domid);
domain->nid = -1;
memset(domain->iommu_bmp, 0, sizeof(domain->iommu_bmp));
domain->flags = DOMAIN_FLAG_VIRTUAL_MACHINE;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 08/20] iommu/vt-d, trivial: clean up unused code
Remove dead code from VT-d related files.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c|2 --
drivers/iommu/intel-iommu.c | 25 -
2 files changed, 27 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 70612a9..9a76073 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1121,8 +1121,6 @@ static const char *irq_remap_fault_reasons[] =
"Blocked an interrupt request due to source-id verification failure",
};
-#define MAX_FAULT_REASON_IDX (ARRAY_SIZE(fault_reason_strings) - 1)
-
const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
{
if (fault_reason >= 0x20 && (fault_reason - 0x20 <
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 68bce9d..b5f13e4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -289,26 +289,6 @@ static inline void dma_clear_pte(struct dma_pte *pte)
pte->val = 0;
}
-static inline void dma_set_pte_readable(struct dma_pte *pte)
-{
- pte->val |= DMA_PTE_READ;
-}
-
-static inline void dma_set_pte_writable(struct dma_pte *pte)
-{
- pte->val |= DMA_PTE_WRITE;
-}
-
-static inline void dma_set_pte_snp(struct dma_pte *pte)
-{
- pte->val |= DMA_PTE_SNP;
-}
-
-static inline void dma_set_pte_prot(struct dma_pte *pte, unsigned long prot)
-{
- pte->val = (pte->val & ~3) | (prot & 3);
-}
-
static inline u64 dma_pte_addr(struct dma_pte *pte)
{
#ifdef CONFIG_64BIT
@@ -319,11 +299,6 @@ static inline u64 dma_pte_addr(struct dma_pte *pte)
#endif
}
-static inline void dma_set_pte_pfn(struct dma_pte *pte, unsigned long pfn)
-{
- pte->val |= (uint64_t)pfn << VTD_PAGE_SHIFT;
-}
-
static inline bool dma_pte_present(struct dma_pte *pte)
{
return (pte->val & 3) != 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 10/20] iommu/vt-d, trivial: use defined macro instead of hardcoding
Use defined macro instead of hardcoding in function set_ioapic_sid() for readability. Signed-off-by: Jiang Liu --- drivers/iommu/intel_irq_remapping.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index 41e5798..50fd55c 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -324,7 +324,7 @@ static int set_ioapic_sid(struct irte *irte, int apic) return -1; } - set_irte_sid(irte, 1, 0, sid); + set_irte_sid(irte, SVT_VERIFY_SID_SQ, SQ_ALL_16, sid); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 06/20] iommu/vt-d, trivial: print correct domain id of static identity domain
Field si_domain->id is set by iommu_attach_domain(), so we could only
print domain id for static identity domain after calling
iommu_attach_domain(si_domain, iommu).
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 70bc071..68bce9d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2246,8 +2246,6 @@ static int __init si_domain_init(int hw)
if (!si_domain)
return -EFAULT;
- pr_debug("Identity mapping domain is domain %d\n", si_domain->id);
-
for_each_active_iommu(iommu, drhd) {
ret = iommu_attach_domain(si_domain, iommu);
if (ret) {
@@ -2262,6 +2260,7 @@ static int __init si_domain_init(int hw)
}
si_domain->flags = DOMAIN_FLAG_STATIC_IDENTITY;
+ pr_debug("Identity mapping domain is domain %d\n", si_domain->id);
if (hw)
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 14/20] iommu/vt-d: avoid double free in error recovery path
The g_iommus array will be freed twice when failed to initialize IOMMU
devices, which will cause system panic.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index cbdb1ff..1a20171 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1293,19 +1293,10 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
iommu->domains = NULL;
iommu->domain_ids = NULL;
- g_iommus[iommu->seq_id] = NULL;
-
- /* if all iommus are freed, free g_iommus */
- for (i = 0; i < g_num_of_iommus; i++) {
- if (g_iommus[i])
- break;
- }
-
- if (i == g_num_of_iommus)
- kfree(g_iommus);
-
/* free context mapping */
free_context_table(iommu);
+
+ g_iommus[iommu->seq_id] = NULL;
}
static struct dmar_domain *alloc_domain(void)
@@ -2621,6 +2612,7 @@ error:
for_each_active_iommu(iommu, drhd)
free_dmar_iommu(iommu);
kfree(g_iommus);
+ g_iommus = NULL;
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 15/20] iommu/vt-d: fix access after free issue in function free_dmar_iommu()
Function free_dmar_iommu() may access domain->iommu_lock by
spin_unlock_irqrestore(>iommu_lock, flags);
after freeing corresponding domain structure.
Sample stack dump:
[8.912818] =
[8.917072] [ BUG: held lock freed! ]
[8.921335] 3.13.0-rc1-gerry+ #12 Not tainted
[8.926375] -
[8.930629] swapper/0/1 is freeing memory 880c23b56040-880c23b5613f,
with a lock still held there!
[8.941675] (&(>iommu_lock)->rlock){..}, at:
[] init_dmars+0x72c/0x95b
[8.952582] 1 lock held by swapper/0/1:
[8.957031] #0: (&(>iommu_lock)->rlock){..}, at:
[] init_dmars+0x72c/0x95b
[8.968487]
[8.968487] stack backtrace:
[8.973602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ #12
[8.981556] Hardware name: Intel Corporation LH Pass ../SVRBD-ROW_T,
BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[8.994742] 880c23b56040 88042dd33c98 815617fd
88042dd38b28
[9.003566] 88042dd33cd0 810a977a 880c23b56040
0086
[9.012403] 88102c4923c0 88042ddb4800 81b1e8c0
88042dd33d28
[9.021240] Call Trace:
[9.024138] [] dump_stack+0x4d/0x66
[9.030057] [] debug_check_no_locks_freed+0x15a/0x160
[9.037723] [] kmem_cache_free+0x62/0x5b0
[9.044225] [] domain_exit+0x197/0x1c0
[9.050418] [] init_dmars+0x758/0x95b
[9.056527] [] intel_iommu_init+0x351/0x438
[9.063207] [] ? iommu_setup+0x27d/0x27d
[9.069601] [] pci_iommu_init+0x28/0x52
[9.075910] [] do_one_initcall+0x122/0x180
[9.082509] [] ? parse_args+0x1e8/0x320
[9.088815] [] kernel_init_freeable+0x1e1/0x26c
[9.095895] [] ? do_early_param+0x88/0x88
[9.102396] [] ? rest_init+0xd0/0xd0
[9.108410] [] kernel_init+0xe/0x130
[9.114423] [] ret_from_fork+0x7c/0xb0
[9.120612] [] ? rest_init+0xd0/0xd0
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 1a20171..fc3473b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1266,7 +1266,7 @@ static void vm_domain_exit(struct dmar_domain *domain);
static void free_dmar_iommu(struct intel_iommu *iommu)
{
struct dmar_domain *domain;
- int i;
+ int i, count;
unsigned long flags;
if ((iommu->domains) && (iommu->domain_ids)) {
@@ -1275,13 +1275,14 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
clear_bit(i, iommu->domain_ids);
spin_lock_irqsave(>iommu_lock, flags);
- if (--domain->iommu_count == 0) {
+ count = --domain->iommu_count;
+ spin_unlock_irqrestore(>iommu_lock, flags);
+ if (count == 0) {
if (domain->flags & DOMAIN_FLAG_VIRTUAL_MACHINE)
vm_domain_exit(domain);
else
domain_exit(domain);
}
- spin_unlock_irqrestore(>iommu_lock, flags);
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 12/20] iommu/vt-d: fix invalid memory access when freeing DMAR irq
In function free_dmar_iommu(), it sets IRQ handler data to NULL
before calling free_irq(), which will cause invalid memory access
because free_irq() will access IRQ handler data when calling
function dmar_msi_mask(). So only set IRQ handler data to NULL
after calling free_irq().
Sample stack dump:
[ 13.094010] BUG: unable to handle kernel NULL pointer dereference at
0048
[ 13.103215] IP: [] __lock_acquire+0x4d/0x12a0
[ 13.110104] PGD 0
[ 13.112614] Oops: [#1] SMP
[ 13.116585] Modules linked in:
[ 13.120260] CPU: 60 PID: 1 Comm: swapper/0 Tainted: GW
3.13.0-rc1-gerry+ #9
[ 13.129367] Hardware name: Intel Corporation LH Pass ../SVRBD-ROW_T,
BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[ 13.142555] task: 88042dd38010 ti: 88042dd32000 task.ti:
88042dd32000
[ 13.151179] RIP: 0010:[] []
__lock_acquire+0x4d/0x12a0
[ 13.160867] RSP: :88042dd33b78 EFLAGS: 00010046
[ 13.166969] RAX: 0046 RBX: 0002 RCX:
[ 13.175122] RDX: RSI: RDI: 0048
[ 13.183274] RBP: 88042dd33bd8 R08: 0002 R09: 0001
[ 13.191417] R10: R11: 0001 R12: 88042dd38010
[ 13.199571] R13: R14: 0048 R15:
[ 13.207725] FS: () GS:88103f20()
knlGS:
[ 13.217014] CS: 0010 DS: ES: CR0: 80050033
[ 13.223596] CR2: 0048 CR3: 01a0b000 CR4: 000407e0
[ 13.231747] Stack:
[ 13.234160] 0004 0046 88042dd33b98
810a567d
[ 13.243059] 88042dd33c08 810bb14c 828995a0
0046
[ 13.251969] 0002
[ 13.260862] Call Trace:
[ 13.263775] [] ? trace_hardirqs_off+0xd/0x10
[ 13.270571] [] ? vprintk_emit+0x23c/0x570
[ 13.277058] [] lock_acquire+0x93/0x120
[ 13.283269] [] ? dmar_msi_mask+0x47/0x70
[ 13.289677] [] _raw_spin_lock_irqsave+0x49/0x90
[ 13.296748] [] ? dmar_msi_mask+0x47/0x70
[ 13.303153] [] dmar_msi_mask+0x47/0x70
[ 13.309354] [] irq_shutdown+0x53/0x60
[ 13.315467] [] __free_irq+0x26d/0x280
[ 13.321580] [] free_irq+0xf0/0x180
[ 13.327395] [] free_dmar_iommu+0x271/0x2b0
[ 13.333996] [] ? trace_hardirqs_on+0xd/0x10
[ 13.340696] [] free_iommu+0x17/0x50
[ 13.346597] [] init_dmars+0x691/0x77a
[ 13.352711] [] intel_iommu_init+0x351/0x438
[ 13.359400] [] ? iommu_setup+0x27d/0x27d
[ 13.365806] [] pci_iommu_init+0x28/0x52
[ 13.372114] [] do_one_initcall+0x122/0x180
[ 13.378707] [] ? parse_args+0x1e8/0x320
[ 13.385016] [] kernel_init_freeable+0x1e1/0x26c
[ 13.392100] [] ? do_early_param+0x88/0x88
[ 13.398596] [] ? rest_init+0xd0/0xd0
[ 13.404614] [] kernel_init+0xe/0x130
[ 13.410626] [] ret_from_fork+0x7c/0xb0
[ 13.416829] [] ? rest_init+0xd0/0xd0
[ 13.422842] Code: ec 99 00 85 c0 8b 05 53 05 a5 00 41 0f 45 d8 85 c0 0f 84
ff 00 00 00 8b 05 99 f9 7e 01 49 89 fe 41 89 f7 85 c0 0f 84 03 01 00 00 <49> 8b
06 be 01 00 00 00 48 3d c0 0e 01 82 0f 44 de 41 83 ff 01
[ 13.450191] RIP [] __lock_acquire+0x4d/0x12a0
[ 13.458598] RSP
[ 13.462671] CR2: 0048
[ 13.466551] ---[ end trace c5bd26a37c81d760 ]---
Reviewed-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0ec49da..426095e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1289,9 +1289,9 @@ void free_dmar_iommu(struct intel_iommu *iommu)
iommu_disable_translation(iommu);
if (iommu->irq) {
- irq_set_handler_data(iommu->irq, NULL);
/* This will mask the irq */
free_irq(iommu->irq, iommu);
+ irq_set_handler_data(iommu->irq, NULL);
destroy_irq(iommu->irq);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 18/20] iommu/vt-d, PCI, trivial: use dev_is_pci() instead of hardcoding
Use helper dev_is_pci() instead of hardcoding. Signed-off-by: Jiang Liu --- drivers/iommu/intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index fc3473b..c1831d7 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2700,7 +2700,7 @@ static int iommu_no_mapping(struct device *dev) struct pci_dev *pdev; int found; - if (unlikely(dev->bus != _bus_type)) + if (unlikely(!dev_is_pci(dev))) return 1; pdev = to_pci_dev(dev); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 16/20] iommu/vt-d: release invalidation queue when destroying IOMMU unit
Release associated invalidation queue when destroying IOMMU unit
to avoid memory leak.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 812b596..a9d9d0f 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -745,6 +745,12 @@ static void free_iommu(struct intel_iommu *iommu)
destroy_irq(iommu->irq);
}
+ if (iommu->qi) {
+ free_page((unsigned long)iommu->qi->desc);
+ kfree(iommu->qi->desc_status);
+ kfree(iommu->qi);
+ }
+
if (iommu->reg)
unmap_iommu(iommu);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 19/20] iommu/vt-d, trivial: clean sparse warnings
Clean up most sparse warnings in Intel DMA and interrupt remapping
drivers.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c|8
drivers/iommu/intel-iommu.c |4 ++--
drivers/iommu/intel_irq_remapping.c |4 ++--
drivers/iommu/irq_remapping.c |6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index b6b8a7f5..f05e2fc 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -580,7 +580,7 @@ static int __init detect_intel_iommu(void)
x86_init.iommu.iommu_init = intel_iommu_init;
#endif
}
- early_acpi_os_unmap_memory(dmar_tbl, dmar_tbl_size);
+ early_acpi_os_unmap_memory((void __iomem *)dmar_tbl, dmar_tbl_size);
dmar_tbl = NULL;
return ret ? 1 : -ENODEV;
@@ -1072,7 +1072,7 @@ int dmar_enable_qi(struct intel_iommu *iommu)
desc_page = alloc_pages_node(iommu->node, GFP_ATOMIC | __GFP_ZERO, 0);
if (!desc_page) {
kfree(qi);
- iommu->qi = 0;
+ iommu->qi = NULL;
return -ENOMEM;
}
@@ -1082,7 +1082,7 @@ int dmar_enable_qi(struct intel_iommu *iommu)
if (!qi->desc_status) {
free_page((unsigned long) qi->desc);
kfree(qi);
- iommu->qi = 0;
+ iommu->qi = NULL;
return -ENOMEM;
}
@@ -1133,7 +1133,7 @@ static const char *irq_remap_fault_reasons[] =
"Blocked an interrupt request due to source-id verification failure",
};
-const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
+static const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
{
if (fault_reason >= 0x20 && (fault_reason - 0x20 <
ARRAY_SIZE(irq_remap_fault_reasons))) {
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c1831d7..87ea78b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -382,7 +382,7 @@ struct device_domain_info {
static void flush_unmaps_timeout(unsigned long data);
-DEFINE_TIMER(unmap_timer, flush_unmaps_timeout, 0, 0);
+static DEFINE_TIMER(unmap_timer, flush_unmaps_timeout, 0, 0);
#define HIGH_WATER_MARK 250
struct deferred_flush_tables {
@@ -3124,7 +3124,7 @@ static int intel_mapping_error(struct device *dev,
dma_addr_t dma_addr)
return !dma_addr;
}
-struct dma_map_ops intel_dma_ops = {
+static struct dma_map_ops intel_dma_ops = {
.alloc = intel_alloc_coherent,
.free = intel_free_coherent,
.map_sg = intel_map_sg,
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 7b4bdaa..aabdc71 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -48,7 +48,7 @@ static struct irq_2_iommu *irq_2_iommu(unsigned int irq)
return cfg ? >irq_2_iommu : NULL;
}
-int get_irte(int irq, struct irte *entry)
+static int get_irte(int irq, struct irte *entry)
{
struct irq_2_iommu *irq_iommu = irq_2_iommu(irq);
unsigned long flags;
@@ -795,7 +795,7 @@ static int __init parse_ioapics_under_ir(void)
return 1;
}
-int __init ir_dev_scope_init(void)
+static int __init ir_dev_scope_init(void)
{
if (!irq_remapping_enabled)
return 0;
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 39f81ae..228632c9 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -150,7 +150,7 @@ static int irq_remapping_setup_msi_irqs(struct pci_dev *dev,
return do_setup_msix_irqs(dev, nvec);
}
-void eoi_ioapic_pin_remapped(int apic, int pin, int vector)
+static void eoi_ioapic_pin_remapped(int apic, int pin, int vector)
{
/*
* Intr-remapping uses pin number as the virtual vector
@@ -295,8 +295,8 @@ int setup_ioapic_remapped_entry(int irq,
vector, attr);
}
-int set_remapped_irq_affinity(struct irq_data *data, const struct cpumask
*mask,
- bool force)
+static int set_remapped_irq_affinity(struct irq_data *data,
+const struct cpumask *mask, bool force)
{
if (!config_enabled(CONFIG_SMP) || !remap_ops ||
!remap_ops->set_affinity)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 13/20] iommu/vt-d: keep shared resources when failed to initialize iommu devices
Data structure drhd->iommu is shared between DMA remapping driver and
interrupt remapping driver, so DMA remapping driver shouldn't release
drhd->iommu when it failed to initialize IOMMU devices. Otherwise it
may cause invalid memory access to the interrupt remapping driver.
Sample stack dump:
[ 13.315090] BUG: unable to handle kernel paging request at c9000605a088
[ 13.323221] IP: [] qi_submit_sync+0x15c/0x400
[ 13.330107] PGD 82f81e067 PUD c2f81e067 PMD 82e846067 PTE 0
[ 13.336818] Oops: 0002 [#1] SMP
[ 13.340757] Modules linked in:
[ 13.344422] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.13.0-rc1-gerry+ #7
[ 13.352474] Hardware name: Intel Corporation LH Pass ../SVRBD-ROW_T,
BIOS
SE5C600.86B.99.99.x059.091020121352 09/10/2012
[ 13.365659] Workqueue: events work_for_cpu_fn
[ 13.370774] task: 88042ddf00d0 ti: 88042ddee000 task.ti:
88042dde e000
[ 13.379389] RIP: 0010:[] []
qi_submit_sy nc+0x15c/0x400
[ 13.389055] RSP: :88042ddef940 EFLAGS: 00010002
[ 13.395151] RAX: 05e0 RBX: 0082 RCX: 00020025
[ 13.403308] RDX: c9000605a000 RSI: 0010 RDI: 88042ddb8610
[ 13.411446] RBP: 88042ddef9a0 R08: 05d0 R09: 0001
[ 13.419599] R10: R11: 005d R12: 005c
[ 13.427742] R13: 88102d84d300 R14: 0174 R15: 88042ddb4800
[ 13.435877] FS: () GS:88043de0()
knlGS:0 000
[ 13.445168] CS: 0010 DS: ES: CR0: 80050033
[ 13.451749] CR2: c9000605a088 CR3: 01a0b000 CR4: 000407f0
[ 13.459895] Stack:
[ 13.462297] 88042ddb85d0 005d 88042ddef9b0
0 5d0
[ 13.471147] 05c0 88042ddb8000 005c
0 015
[ 13.480001] 88042ddb4800 0282 88042ddefa40
88042ddef ac0
[ 13.488855] Call Trace:
[ 13.491771] [] modify_irte+0x9d/0xd0
[ 13.497778] [] intel_setup_ioapic_entry+0x10d/0x290
[ 13.505250] [] ? trace_hardirqs_on_caller+0x16/0x1e0
[ 13.512824] [] ? default_init_apic_ldr+0x60/0x60
[ 13.519998] [] setup_ioapic_remapped_entry+0x20/0x30
[ 13.527566] [] io_apic_setup_irq_pin+0x12a/0x2c0
[ 13.534742] [] ? acpi_pci_irq_find_prt_entry+0x2b9/0x2d8
[ 13.544102] [] io_apic_setup_irq_pin_once+0x85/0xa0
[ 13.551568] [] ? mp_find_ioapic_pin+0x8f/0xf0
[ 13.558434] [] io_apic_set_pci_routing+0x34/0x70
[ 13.565621] [] mp_register_gsi+0xaf/0x1c0
[ 13.572111] [] acpi_register_gsi_ioapic+0xe/0x10
[ 13.579286] [] acpi_register_gsi+0xf/0x20
[ 13.585779] [] acpi_pci_irq_enable+0x171/0x1e3
[ 13.592764] [] pcibios_enable_device+0x31/0x40
[ 13.599744] [] do_pci_enable_device+0x3b/0x60
[ 13.606633] [] pci_enable_device_flags+0xc8/0x120
[ 13.613887] [] pci_enable_device+0x13/0x20
[ 13.620484] [] pcie_port_device_register+0x1e/0x510
[ 13.627947] [] ? trace_hardirqs_on_caller+0x16/0x1e0
[ 13.635510] [] ? trace_hardirqs_on+0xd/0x10
[ 13.642189] [] pcie_portdrv_probe+0x58/0xc0
[ 13.648877] [] local_pci_probe+0x45/0xa0
[ 13.655266] [] work_for_cpu_fn+0x14/0x20
[ 13.661656] [] process_one_work+0x369/0x710
[ 13.668334] [] ? process_one_work+0x2f2/0x710
[ 13.675215] [] ? worker_thread+0x46/0x690
[ 13.681714] [] worker_thread+0x484/0x690
[ 13.688109] [] ? cancel_delayed_work_sync+0x20/0x20
[ 13.695576] [] kthread+0xf0/0x110
[ 13.701300] [] ? local_clock+0x3f/0x50
[ 13.707492] [] ? kthread_create_on_node+0x250/0x250
[ 13.714959] [] ret_from_fork+0x7c/0xb0
[ 13.721152] [] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c | 51 +++--
drivers/iommu/intel-iommu.c | 13 ---
include/linux/dma_remapping.h |4
include/linux/intel-iommu.h |1 -
4 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 99fb0c2..812b596 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -53,6 +53,7 @@ struct acpi_table_header * __initdata dmar_tbl;
static acpi_size dmar_tbl_size;
static int alloc_iommu(struct dmar_drhd_unit *drhd);
+static void free_iommu(struct intel_iommu *iommu);
static void __init dmar_register_drhd_unit(struct dmar_drhd_unit *drhd)
{
@@ -205,25 +206,28 @@ dmar_parse_one_drhd(struct acpi_dmar_header *header)
return 0;
}
+static void dmar_free_drhd(struct dmar_drhd_unit *dmaru)
+{
+ if (dmaru->devices && dmaru->devices_cnt)
+ dmar_free_dev_scope(>devices,
[Patch Part1 V2 17/20] iommu/vt-d: fix wrong return value of dmar_table_init()
If dmar_table_init() fails to detect DMAR table on the first call,
it will return wrong result on following calls because it always
sets dmar_table_initialized no matter if succeeds or fails to
detect DMAR table.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index a9d9d0f..b6b8a7f5 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -472,24 +472,23 @@ int __init dmar_table_init(void)
static int dmar_table_initialized;
int ret;
- if (dmar_table_initialized)
- return 0;
-
- dmar_table_initialized = 1;
-
- ret = parse_dmar_table();
- if (ret) {
- if (ret != -ENODEV)
- pr_info("parse DMAR table failure.\n");
- return ret;
- }
+ if (dmar_table_initialized == 0) {
+ ret = parse_dmar_table();
+ if (ret < 0) {
+ if (ret != -ENODEV)
+ pr_info("parse DMAR table failure.\n");
+ } else if (list_empty(_drhd_units)) {
+ pr_info("No DMAR devices found\n");
+ ret = -ENODEV;
+ }
- if (list_empty(_drhd_units)) {
- pr_info("No DMAR devices found\n");
- return -ENODEV;
+ if (ret < 0)
+ dmar_table_initialized = ret;
+ else
+ dmar_table_initialized = 1;
}
- return 0;
+ return dmar_table_initialized < 0 ? dmar_table_initialized : 0;
}
static void warn_invalid_dmar(u64 addr, const char *message)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 20/20] iommu/vt-d: free all resources if failed to initialize DMARs
Enhance intel_iommu_init() to free all resources if failed to
initialize DMAR hardware.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 80 ++-
1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 87ea78b..27b270b4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2612,6 +2612,7 @@ static int __init init_dmars(void)
error:
for_each_active_iommu(iommu, drhd)
free_dmar_iommu(iommu);
+ kfree(deferred_flush);
kfree(g_iommus);
g_iommus = NULL;
return ret;
@@ -3456,18 +3457,12 @@ static int __init
rmrr_parse_dev(struct dmar_rmrr_unit *rmrru)
{
struct acpi_dmar_reserved_memory *rmrr;
- int ret;
rmrr = (struct acpi_dmar_reserved_memory *) rmrru->hdr;
- ret = dmar_parse_dev_scope((void *)(rmrr + 1),
- ((void *)rmrr) + rmrr->header.length,
- >devices_cnt, >devices, rmrr->segment);
-
- if (ret || (rmrru->devices_cnt == 0)) {
- list_del(>list);
- kfree(rmrru);
- }
- return ret;
+ return dmar_parse_dev_scope((void *)(rmrr + 1),
+ ((void *)rmrr) + rmrr->header.length,
+ >devices_cnt, >devices,
+ rmrr->segment);
}
static LIST_HEAD(dmar_atsr_units);
@@ -3492,23 +3487,38 @@ int __init dmar_parse_one_atsr(struct acpi_dmar_header
*hdr)
static int __init atsr_parse_dev(struct dmar_atsr_unit *atsru)
{
- int rc;
struct acpi_dmar_atsr *atsr;
if (atsru->include_all)
return 0;
atsr = container_of(atsru->hdr, struct acpi_dmar_atsr, header);
- rc = dmar_parse_dev_scope((void *)(atsr + 1),
- (void *)atsr + atsr->header.length,
- >devices_cnt, >devices,
- atsr->segment);
- if (rc || !atsru->devices_cnt) {
- list_del(>list);
- kfree(atsru);
+ return dmar_parse_dev_scope((void *)(atsr + 1),
+ (void *)atsr + atsr->header.length,
+ >devices_cnt, >devices,
+ atsr->segment);
+}
+
+static void intel_iommu_free_atsr(struct dmar_atsr_unit *atsru)
+{
+ dmar_free_dev_scope(>devices, >devices_cnt);
+ list_del(>list);
+ kfree(atsru);
+}
+
+static void intel_iommu_free_dmars(void)
+{
+ struct dmar_rmrr_unit *rmrru, *rmrr_n;
+ struct dmar_atsr_unit *atsru, *atsr_n;
+
+ list_for_each_entry_safe(rmrru, rmrr_n, _rmrr_units, list) {
+ dmar_free_dev_scope(>devices, >devices_cnt);
+ list_del(>list);
+ kfree(rmrru);
}
- return rc;
+ list_for_each_entry_safe(atsru, atsr_n, _atsr_units, list)
+ intel_iommu_free_atsr(atsru);
}
int dmar_find_matched_atsr_unit(struct pci_dev *dev)
@@ -3552,17 +3562,17 @@ found:
int __init dmar_parse_rmrr_atsr_dev(void)
{
- struct dmar_rmrr_unit *rmrr, *rmrr_n;
- struct dmar_atsr_unit *atsr, *atsr_n;
+ struct dmar_rmrr_unit *rmrr;
+ struct dmar_atsr_unit *atsr;
int ret = 0;
- list_for_each_entry_safe(rmrr, rmrr_n, _rmrr_units, list) {
+ list_for_each_entry(rmrr, _rmrr_units, list) {
ret = rmrr_parse_dev(rmrr);
if (ret)
return ret;
}
- list_for_each_entry_safe(atsr, atsr_n, _atsr_units, list) {
+ list_for_each_entry(atsr, _atsr_units, list) {
ret = atsr_parse_dev(atsr);
if (ret)
return ret;
@@ -3609,7 +3619,7 @@ static struct notifier_block device_nb = {
int __init intel_iommu_init(void)
{
- int ret = 0;
+ int ret = -ENODEV;
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
@@ -3619,7 +3629,7 @@ int __init intel_iommu_init(void)
if (dmar_table_init()) {
if (force_on)
panic("tboot: Failed to initialize DMAR table\n");
- return -ENODEV;
+ goto out_free_dmar;
}
/*
@@ -3632,16 +3642,16 @@ int __init intel_iommu_init(void)
if (dmar_dev_scope_init() < 0) {
if (force_on)
panic("tboot: Failed to initialize DMAR device
scope\n");
- return -ENODEV;
+ goto out_free_dmar;
}
if (no_iommu || dmar_disabled)
- return -ENODEV;
+ goto out_free_dmar;
if (iommu_init_mempool()) {
if (force_on)
panic("tboot: Failed to initialize iommu memory\n");
- return -ENODEV;
+ goto out_free_dmar;
}
if
[Patch Part1 V2 07/20] iommu/vt-d, trivial: check suitable flag in function detect_intel_iommu()
Flag irq_remapping_enabled is only set by intel_enable_irq_remapping(),
which is called after detect_intel_iommu(). So we should check flag
disable_irq_remap instead of irq_remapping_enabled in function
detect_intel_iommu().
Reviewed-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index c17dbf7..70612a9 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -560,7 +560,7 @@ int __init detect_intel_iommu(void)
dmar = (struct acpi_table_dmar *) dmar_tbl;
- if (ret && irq_remapping_enabled && cpu_has_x2apic &&
+ if (ret && !disable_irq_remap && cpu_has_x2apic &&
dmar->flags & 0x1)
pr_info("Queued invalidation will be enabled to support
x2apic and Intr-remapping.\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 09/20] iommu/vt-d: mark internal functions as static
Function detect_intel_iommu()/alloc_iommu()/parse_ioapics_under_ir()
are only used internally, so mark them as static.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c|9 ++---
drivers/iommu/intel_irq_remapping.c |4 +++-
include/linux/dmar.h| 12 +---
include/linux/intel-iommu.h |1 -
4 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a76073..4bbd972 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -52,6 +52,8 @@ LIST_HEAD(dmar_drhd_units);
struct acpi_table_header * __initdata dmar_tbl;
static acpi_size dmar_tbl_size;
+static int alloc_iommu(struct dmar_drhd_unit *drhd);
+
static void __init dmar_register_drhd_unit(struct dmar_drhd_unit *drhd)
{
/*
@@ -498,7 +500,7 @@ static void warn_invalid_dmar(u64 addr, const char *message)
dmi_get_system_info(DMI_PRODUCT_VERSION));
}
-int __init check_zero_address(void)
+static int __init check_zero_address(void)
{
struct acpi_table_dmar *dmar;
struct acpi_dmar_header *entry_header;
@@ -548,7 +550,7 @@ failed:
return 0;
}
-int __init detect_intel_iommu(void)
+static int __init detect_intel_iommu(void)
{
int ret;
@@ -657,7 +659,7 @@ out:
return err;
}
-int alloc_iommu(struct dmar_drhd_unit *drhd)
+static int alloc_iommu(struct dmar_drhd_unit *drhd)
{
struct intel_iommu *iommu;
u32 ver, sts;
@@ -1374,4 +1376,5 @@ int __init dmar_ir_support(void)
return 0;
return dmar->flags & 0x1;
}
+
IOMMU_INIT_POST(detect_intel_iommu);
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 282d392..41e5798 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -40,6 +40,8 @@ static int ir_ioapic_num, ir_hpet_num;
static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
+static int __init parse_ioapics_under_ir(void);
+
static struct irq_2_iommu *irq_2_iommu(unsigned int irq)
{
struct irq_cfg *cfg = irq_get_chip_data(irq);
@@ -771,7 +773,7 @@ static int ir_parse_ioapic_hpet_scope(struct
acpi_dmar_header *header,
* Finds the assocaition between IOAPIC's and its Interrupt-remapping
* hardware unit.
*/
-int __init parse_ioapics_under_ir(void)
+static int __init parse_ioapics_under_ir(void)
{
struct dmar_drhd_unit *drhd;
int ir_supported = 0;
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 8adfce0..f614357 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -33,6 +33,7 @@ struct acpi_dmar_header;
#define DMAR_X2APIC_OPT_OUT0x2
struct intel_iommu;
+
#ifdef CONFIG_DMAR_TABLE
extern struct acpi_table_header *dmar_tbl;
struct dmar_drhd_unit {
@@ -62,19 +63,8 @@ extern struct list_head dmar_drhd_units;
extern int dmar_table_init(void);
extern int dmar_dev_scope_init(void);
-
-/* Intel IOMMU detection */
-extern int detect_intel_iommu(void);
extern int enable_drhd_fault_handling(void);
-
-extern int parse_ioapics_under_ir(void);
-extern int alloc_iommu(struct dmar_drhd_unit *);
#else
-static inline int detect_intel_iommu(void)
-{
- return -ENODEV;
-}
-
static inline int dmar_table_init(void)
{
return -ENODEV;
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index de1e5e9..f2c4114 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -348,7 +348,6 @@ static inline void __iommu_flush_cache(
extern struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev
*dev);
extern int dmar_find_matched_atsr_unit(struct pci_dev *dev);
-extern int alloc_iommu(struct dmar_drhd_unit *drhd);
extern void free_iommu(struct intel_iommu *iommu);
extern int dmar_enable_qi(struct intel_iommu *iommu);
extern void dmar_disable_qi(struct intel_iommu *iommu);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] virtio: delete napi structures from netdev before releasing memory
On 12/05/2013 10:36 PM, Andrey Vagin wrote:
> free_netdev calls netif_napi_del too, but it's too late, because napi
> structures are placed on vi->rq. netif_napi_add() is called from
> virtnet_alloc_queues.
>
> general protection fault: [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables
> virtio_balloon pcspkr virtio_net(-) i2c_pii
> CPU: 1 PID: 347 Comm: rmmod Not tainted 3.13.0-rc2+ #171
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> task: 8800b779c420 ti: 8800379e task.ti: 8800379e
> RIP: 0010:[] []
> __list_del_entry+0x29/0xd0
> RSP: 0018:8800379e1dd0 EFLAGS: 00010a83
> RAX: 6b6b6b6b6b6b6b6b RBX: 8800379c2fd0 RCX: dead00200200
> RDX: 6b6b6b6b6b6b6b6b RSI: 0001 RDI: 8800379c2fd0
> RBP: 8800379e1dd0 R08: 0001 R09:
> R10: R11: 0001 R12: 8800379c2f90
> R13: 880037839160 R14: R15: 013352f0
> FS: 7f1400e34740() GS:8800bfb0() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 7f464124c763 CR3: b68cf000 CR4: 06e0
> Stack:
> 8800379e1df0 8155beab 6b6b6b6b6b6b6b2b 8800378391c0
> 8800379e1e18 8156499b 880037839be0 880037839d20
> 88003779d3f0 8800379e1e38 a003477c 88003779d388
> Call Trace:
> [] netif_napi_del+0x1b/0x80
> [] free_netdev+0x8b/0x110
> [] virtnet_remove+0x7c/0x90 [virtio_net]
> [] virtio_dev_remove+0x23/0x80
> [] __device_release_driver+0x7f/0xf0
> [] driver_detach+0xc0/0xd0
> [] bus_remove_driver+0x58/0xd0
> [] driver_unregister+0x2c/0x50
> [] unregister_virtio_driver+0xe/0x10
> [] virtio_net_driver_exit+0x10/0x6ce [virtio_net]
> [] SyS_delete_module+0x172/0x220
> [] ? trace_hardirqs_on+0xd/0x10
> [] ? __audit_syscall_entry+0x9c/0xf0
> [] system_call_fastpath+0x16/0x1b
> Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48
> 39 ca 74 29 48 b9 00 02 20 00 00 00
> RIP [] __list_del_entry+0x29/0xd0
> RSP
> ---[ end trace d5931cd3f87c9763 ]---
>
> Fixes: 986a4f4d452d (virtio_net: multiqueue support)
> Cc: Rusty Russell
> Cc: "Michael S. Tsirkin"
> Signed-off-by: Andrey Vagin
> ---
> drivers/net/virtio_net.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 930039a..c293764 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1367,6 +1367,11 @@ static void virtnet_config_changed(struct
> virtio_device *vdev)
>
> static void virtnet_free_queues(struct virtnet_info *vi)
> {
> + int i;
> +
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + netif_napi_del(>rq[i].napi);
> +
> kfree(vi->rq);
> kfree(vi->sq);
> }
Acked-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part1 V2 11/20] iommu/vt-d, trivial: simplify code with existing macros
Simplify vt-d related code with existing macros and introduce a new
macro for_each_active_drhd_unit() to enumerate all active DRHD unit.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c|7 ++---
drivers/iommu/intel-iommu.c | 55 ---
drivers/iommu/intel_irq_remapping.c | 31 +++-
include/linux/dmar.h|4 +++
4 files changed, 29 insertions(+), 68 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 4bbd972..99fb0c2 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1313,15 +1313,14 @@ int dmar_set_interrupt(struct intel_iommu *iommu)
int __init enable_drhd_fault_handling(void)
{
struct dmar_drhd_unit *drhd;
+ struct intel_iommu *iommu;
/*
* Enable fault control interrupt.
*/
- for_each_drhd_unit(drhd) {
- int ret;
- struct intel_iommu *iommu = drhd->iommu;
+ for_each_iommu(iommu, drhd) {
u32 fault_status;
- ret = dmar_set_interrupt(iommu);
+ int ret = dmar_set_interrupt(iommu);
if (ret) {
pr_err("DRHD %Lx: failed to enable fault, interrupt,
ret %d\n",
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b5f13e4..0ec49da 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -628,9 +628,7 @@ static struct intel_iommu *device_to_iommu(int segment, u8
bus, u8 devfn)
struct dmar_drhd_unit *drhd = NULL;
int i;
- for_each_drhd_unit(drhd) {
- if (drhd->ignored)
- continue;
+ for_each_active_drhd_unit(drhd) {
if (segment != drhd->segment)
continue;
@@ -2467,11 +2465,7 @@ static int __init init_dmars(void)
goto error;
}
- for_each_drhd_unit(drhd) {
- if (drhd->ignored)
- continue;
-
- iommu = drhd->iommu;
+ for_each_active_iommu(iommu, drhd) {
g_iommus[iommu->seq_id] = iommu;
ret = iommu_init_domains(iommu);
@@ -2495,12 +2489,7 @@ static int __init init_dmars(void)
/*
* Start from the sane iommu hardware state.
*/
- for_each_drhd_unit(drhd) {
- if (drhd->ignored)
- continue;
-
- iommu = drhd->iommu;
-
+ for_each_active_iommu(iommu, drhd) {
/*
* If the queued invalidation is already initialized by us
* (for example, while enabling interrupt-remapping) then
@@ -2520,12 +2509,7 @@ static int __init init_dmars(void)
dmar_disable_qi(iommu);
}
- for_each_drhd_unit(drhd) {
- if (drhd->ignored)
- continue;
-
- iommu = drhd->iommu;
-
+ for_each_active_iommu(iommu, drhd) {
if (dmar_enable_qi(iommu)) {
/*
* Queued Invalidate not enabled, use Register Based
@@ -2608,17 +2592,16 @@ static int __init init_dmars(void)
* global invalidate iotlb
* enable translation
*/
- for_each_drhd_unit(drhd) {
+ for_each_iommu(iommu, drhd) {
if (drhd->ignored) {
/*
* we always have to disable PMRs or DMA may fail on
* this device
*/
if (force_on)
- iommu_disable_protect_mem_regions(drhd->iommu);
+ iommu_disable_protect_mem_regions(iommu);
continue;
}
- iommu = drhd->iommu;
iommu_flush_write_buffer(iommu);
@@ -2640,12 +2623,8 @@ static int __init init_dmars(void)
return 0;
error:
- for_each_drhd_unit(drhd) {
- if (drhd->ignored)
- continue;
- iommu = drhd->iommu;
+ for_each_active_iommu(iommu, drhd)
free_iommu(iommu);
- }
kfree(g_iommus);
return ret;
}
@@ -3293,9 +3272,9 @@ static void __init init_no_remapping_devices(void)
}
}
- for_each_drhd_unit(drhd) {
+ for_each_active_drhd_unit(drhd) {
int i;
- if (drhd->ignored || drhd->include_all)
+ if (drhd->include_all)
continue;
for (i = 0; i < drhd->devices_cnt; i++)
@@ -3644,6 +3623,7 @@ int __init intel_iommu_init(void)
{
int ret = 0;
struct dmar_drhd_unit *drhd;
+ struct intel_iommu *iommu;
/* VT-d is required for a TXT/tboot launch, so enforce that */
force_on = tboot_force_iommu();
@@ -3657,16 +3637,9 @@ int __init intel_iommu_init(void)
/*
[Patch Part1 V2 05/20] iommu/vt-d, trivial: refine support of 64bit guest address
In Intel IOMMU driver, it calculate page table level from adjusted guest
address width as 'level = (agaw - 30) / 9', which assumes (agaw -30)
could be divided by 9. On the other hand, 64bit is a valid agaw and
(64 - 30) can't be divided by 9, so it needs special handling.
This patch enhances Intel IOMMU driver to correctly handle 64bit agaw.
It's mainly for code readability because there's no hardware supporting
64bit agaw yet.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 2398876..70bc071 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -63,6 +63,7 @@
#define DEFAULT_DOMAIN_ADDRESS_WIDTH 48
#define MAX_AGAW_WIDTH 64
+#define MAX_AGAW_PFN_WIDTH (MAX_AGAW_WIDTH - VTD_PAGE_SHIFT)
#define __DOMAIN_MAX_PFN(gaw) uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1)
#define __DOMAIN_MAX_ADDR(gaw) uint64_t)1) << gaw) - 1)
@@ -106,12 +107,12 @@ static inline int agaw_to_level(int agaw)
static inline int agaw_to_width(int agaw)
{
- return 30 + agaw * LEVEL_STRIDE;
+ return min_t(int, 30 + agaw * LEVEL_STRIDE, MAX_AGAW_WIDTH);
}
static inline int width_to_agaw(int width)
{
- return (width - 30) / LEVEL_STRIDE;
+ return DIV_ROUND_UP(width - 30, LEVEL_STRIDE);
}
static inline unsigned int level_to_offset_bits(int level)
@@ -141,7 +142,7 @@ static inline unsigned long align_to_level(unsigned long
pfn, int level)
static inline unsigned long lvl_to_nr_pages(unsigned int lvl)
{
- return 1 << ((lvl - 1) * LEVEL_STRIDE);
+ return 1 << min_t(int, (lvl - 1) * LEVEL_STRIDE, MAX_AGAW_PFN_WIDTH);
}
/* VT-d pages must always be _smaller_ than MM pages. Otherwise things
@@ -865,7 +866,6 @@ static int dma_pte_clear_range(struct dmar_domain *domain,
int addr_width = agaw_to_width(domain->agaw) - VTD_PAGE_SHIFT;
unsigned int large_page = 1;
struct dma_pte *first_pte, *pte;
- int order;
BUG_ON(addr_width < BITS_PER_LONG && start_pfn >> addr_width);
BUG_ON(addr_width < BITS_PER_LONG && last_pfn >> addr_width);
@@ -890,8 +890,7 @@ static int dma_pte_clear_range(struct dmar_domain *domain,
} while (start_pfn && start_pfn <= last_pfn);
- order = (large_page - 1) * 9;
- return order;
+ return min_t(int, (large_page - 1) * 9, MAX_AGAW_PFN_WIDTH);
}
static void dma_pte_free_level(struct dmar_domain *domain, int level,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch Part1 V2 04/20] iommu/vt-d: fix resource leakage on error recovery path in iommu_init_domains()
Release allocated resources on error recovery path in function
iommu_init_domains().
Acked-by: Yijing Wang
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b8e3b48..2398876 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1273,6 +1273,8 @@ static int iommu_init_domains(struct intel_iommu *iommu)
GFP_KERNEL);
if (!iommu->domains) {
printk(KERN_ERR "Allocating domain array failed\n");
+ kfree(iommu->domain_ids);
+ iommu->domain_ids = NULL;
return -ENOMEM;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] pciehp: Use link change notifications for hot-plug and removal
On 12/05/2013 01:07 AM, Yijing Wang wrote:
>
> handle_link_up_event() and handle_link_down_event() are almost the same,
> what about use like:
> handle_link_state_change_event(p_slot, event) to reuse the the common code ?
>
>
Sure, I can combine both of them to make it look more like this. Let me know
it this looks all right.
static void handle_link_event(struct slot *p_slot, unsigned int req)
{
struct controller *ctrl = p_slot->ctrl;
struct power_work_info *info;
info = kmalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
ctrl_err(p_slot->ctrl, "%s: Cannot allocate memory\n",
__func__);
return;
}
info->p_slot = p_slot;
info->req = req;
INIT_WORK(>work, pciehp_power_thread);
switch (p_slot->state) {
case BLINKINGON_STATE:
case BLINKINGOFF_STATE:
cancel_delayed_work(_slot->work);
/* Fall through */
case STATIC_STATE:
if (req == ENABLE_REQ)
p_slot->state = POWERON_STATE;
else
p_slot->state = POWEROFF_STATE;
queue_work(p_slot->wq, >work);
break;
case POWERON_STATE:
if (req == ENABLE_REQ) {
ctrl_info(ctrl,
"Link Up ignored on slot(%s): already
powering on\n",
slot_name(p_slot));
kfree(info);
} else {
ctrl_info(ctrl,
"Link Down queued on slot(%s): currently
getting powered on\n",
slot_name(p_slot));
p_slot->state = POWEROFF_STATE;
queue_work(p_slot->wq, >work);
}
break;
case POWEROFF_STATE:
if (req == ENABLE_REQ) {
ctrl_info(ctrl,
"Link Up queued on slot(%s): currently
getting powered off\n",
slot_name(p_slot));
p_slot->state = POWERON_STATE;
queue_work(p_slot->wq, >work);
} else {
ctrl_info(ctrl,
"Link Down ignored on slot(%s): already
powering off\n",
slot_name(p_slot));
kfree(info);
}
break;
default:
ctrl_err(ctrl, "Not a valid state on slot(%s)\n",
slot_name(p_slot));
kfree(info);
break;
}
}
Bjorn: was wondering if you'd able to take a look at this patchset in
this or next week some time. I'm eagerly waiting to address any comments.
Also, can you please let me know what is the protocol here? Should
I resubmit just the "v3" of this patch? Or bump up the version of all
the patches in the patchset to "v3" and resubmit them all?
Thanks & Best Regards,
Rajat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio-net: determine type of bufs correctly
On 12/05/2013 10:36 PM, Andrey Vagin wrote:
> free_unused_bufs must check vi->mergeable_rx_bufs before
> vi->big_packets, because we use this sequence in other places.
> Otherwise we allocate buffer of one type, then free it as another
> type.
>
> general protection fault: [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables pcspkr
> virtio_balloon virtio_net(-) i2c_pii
> CPU: 0 PID: 400 Comm: rmmod Not tainted 3.13.0-rc2+ #170
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> task: 8800b6d2a210 ti: 8800aed32000 task.ti: 8800aed32000
> RIP: 0010:[] []
> free_unused_bufs+0xc3/0x190 [virtio_net]
> RSP: 0018:8800aed33dd8 EFLAGS: 00010202
> RAX: 8800b1fe2c00 RBX: 8800b66a7240 RCX: 6b6b6b6b6b6b6b6b
> RDX: 6b6b6b6b6b6b6b6b RSI: 8800b8419a68 RDI: 8800b66a1148
> RBP: 8800aed33e00 R08: 0001 R09:
> R10: R11: 0001 R12:
> R13: 8800b66a1148 R14: R15: 77ff8000
> FS: 7fc4f9c4e740() GS:8800bfa0() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 7f63f432f000 CR3: b6538000 CR4: 06f0
> Stack:
> 8800b66a7240 8800b66a7380 8800377bd3f0
> 023302f0 8800aed33e18 a00346e2 8800b66a7240
> 8800aed33e38 a003474d 8800377bd388 8800377bd390
> Call Trace:
> [] remove_vq_common+0x22/0x40 [virtio_net]
> [] virtnet_remove+0x4d/0x90 [virtio_net]
> [] virtio_dev_remove+0x23/0x80
> [] __device_release_driver+0x7f/0xf0
> [] driver_detach+0xc0/0xd0
> [] bus_remove_driver+0x58/0xd0
> [] driver_unregister+0x2c/0x50
> [] unregister_virtio_driver+0xe/0x10
> [] virtio_net_driver_exit+0x10/0x7be [virtio_net]
> [] SyS_delete_module+0x172/0x220
> [] ? trace_hardirqs_on+0xd/0x10
> [] ? __audit_syscall_entry+0x9c/0xf0
> [] system_call_fastpath+0x16/0x1b
> Code: c0 74 55 0f 1f 44 00 00 80 7b 30 00 74 7a 48 8b 50 30 4c 89 e6 48 03 73
> 20 48 85 d2 0f 84 bb 00 00 00 66 0f
> RIP [] free_unused_bufs+0xc3/0x190 [virtio_net]
> RSP
> ---[ end trace edb570ea923cce9c ]---
>
> Fixes: 2613af0ed18a (virtio_net: migrate mergeable rx buffers to page frag
> allocators)
> Cc: Michael Dalton
> Cc: Rusty Russell
> Cc: "Michael S. Tsirkin"
> Signed-off-by: Andrey Vagin
> ---
> drivers/net/virtio_net.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 916241d..930039a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1396,10 +1396,10 @@ static void free_unused_bufs(struct virtnet_info *vi)
> struct virtqueue *vq = vi->rq[i].vq;
>
> while ((buf = virtqueue_detach_unused_buf(vq)) != NULL) {
> - if (vi->big_packets)
> - give_pages(>rq[i], buf);
> - else if (vi->mergeable_rx_bufs)
> + if (vi->mergeable_rx_bufs)
> put_page(virt_to_head_page(buf));
> + else if (vi->big_packets)
> + give_pages(>rq[i], buf);
> else
> dev_kfree_skb(buf);
> --vi->rq[i].num;
Acked-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net/fddi: Replace local marco with PCI standard macro
On 2013/12/6 6:06, Maciej W. Rozycki wrote:
> On Thu, 5 Dec 2013, Yijing Wang wrote:
>
>> Replace local marco DFX_BUS_PCI with PCI standard marco
>> dev_is_pci().
>
> Typos above: marco -> macro
Sorry for the mistake, David, should i need to resend this patch to fix this
typo error?
>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/net/fddi/defxx.c | 20 +++-
>> 1 files changed, 7 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
>> index 0b40e1c..0344f71 100644
>> --- a/drivers/net/fddi/defxx.c
>> +++ b/drivers/net/fddi/defxx.c
>> @@ -241,12 +241,6 @@ static char version[] =
>> */
>> #define NEW_SKB_SIZE (PI_RCV_DATA_K_SIZE_MAX+128)
>>
>> -#ifdef CONFIG_PCI
>> -#define DFX_BUS_PCI(dev) (dev->bus == _bus_type)
>> -#else
>> -#define DFX_BUS_PCI(dev) 0
>> -#endif
>> -
>> #ifdef CONFIG_EISA
>> #define DFX_BUS_EISA(dev) (dev->bus == _bus_type)
>> #else
>> @@ -436,7 +430,7 @@ static void dfx_port_read_long(DFX_board_t *bp, int
>> offset, u32 *data)
>> static void dfx_get_bars(struct device *bdev,
>> resource_size_t *bar_start, resource_size_t *bar_len)
>> {
>> -int dfx_bus_pci = DFX_BUS_PCI(bdev);
>> +int dfx_bus_pci = dev_is_pci(bdev);
>> int dfx_bus_eisa = DFX_BUS_EISA(bdev);
>> int dfx_bus_tc = DFX_BUS_TC(bdev);
>> int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
>
> Acked-by: Maciej W. Rozycki
>
> Maciej
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote: > On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote: > > pxa2xx-uart was a separate uart platform driver. It was declaring > > the same device names and numbers as 8250 driver. As a result, > > it was impossible to use 8250 driver on PXA SoCs. > > > > Upon closer examination pxa2xx-uart turned out to be a clone of > > 8250_core driver. > > I'm testing this backported to 3.5 on the OLPC XO-4 [1] [2]. > > As Russell says, the getty had to change, but after that the shell > worked fine; no more or no less responsive. > > What hasn't worked yet is the console; no kernel messages appear. I > have tried changing command line to console=ttyS0,115200. My error. Our kernel had CONFIG_CMDLINE set, changing that fixed it. Console is working fine. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned out to be a clone of
> 8250_core driver.
[...]
> +/* Uart divisor latch write */
> +static void serial_pxa_dl_write(struct uart_8250_port *up, int value)
> +{
> + serial_out(up, UART_DLL, value & 0xff);
> + serial_out(up, UART_DLM, value >> 8 & 0xff);
> +}
This is a change. drivers/tty/serial/pxa.c did read back UART_DLL as
an errata work around:
> - /*
> - * work around Errata #75 according to Intel(R) PXA27x Processor Family
> - * Specification Update (Nov 2005)
> - */
> - dll = serial_in(up, UART_DLL);
> - WARN_ON(dll != (quot & 0xff));
If this is no longer needed, serial_pxa_dl_write can be removed
because it is same as default_serial_dl_write.
I did not check the other errata work arounds.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH 3/3] f2fs: introduce f2fs_cache_node_page() to add page into node_inode cache
Hi,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Friday, December 06, 2013 9:43 AM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net; 谭姝
> Subject: RE: [f2fs-dev] [PATCH 3/3] f2fs: introduce f2fs_cache_node_page() to
> add page into node_inode cache
>
> Hi,
>
> 2013-12-05 (목), 10:10 +0800, Chao Yu:
> > > -Original Message-
> > > From: Chao Yu [mailto:chao2...@samsung.com]
> > > Sent: Thursday, December 05, 2013 9:55 AM
> > > To: ???
> > > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Subject: [f2fs-dev] [PATCH 3/3] f2fs: introduce f2fs_cache_node_page() to
> > > add page into node_inode cache
> > >
> > > This patch introduces f2fs_cache_node_page(), in this function, page
> > > which is
> > > readed ahead will be copy to node_inode's mapping cache.
> > > It will avoid rereading these node pages.
> > >
> > > Signed-off-by: Chao Yu
> >
> > Suggested-by: Jaegeuk Kim
> >
> > I miss that, my mistake.
> >
> > > ---
> > > fs/f2fs/node.c | 30 ++
> > > 1 file changed, 30 insertions(+)
> > >
> > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > > index 099f06f..5e2588f 100644
> > > --- a/fs/f2fs/node.c
> > > +++ b/fs/f2fs/node.c
> > > @@ -1600,6 +1600,34 @@ static int ra_sum_pages(struct f2fs_sb_info *sbi,
> > > struct list_head *pages,
> > > return 0;
> > > }
> > >
> > > +/*
> > > + * f2fs_cache_node_page() copy updated page data to node_inode cache
> > > page.
> > > + */
> > > +void f2fs_cache_node_page(struct f2fs_sb_info *sbi, struct page *page,
> > > + nid_t nid)
> > > +{
> > > + struct address_space *mapping = sbi->node_inode->i_mapping;
> > > + struct page *npage;
> > > +
> > > + npage = find_get_page(mapping, nid);
> > > + if (npage && PageUptodate(npage)) {
> > > + f2fs_put_page(npage, 0);
> > > + return;
> > > + }
> > > + f2fs_put_page(npage, 0);
> > > +
> > > + npage = grab_cache_page(mapping, nid);
> > > + if (!npage)
> > > + return;
> > > +
>
> I forgot to tell you that we need to check its validity here.
> We should not cache this page all the time.
> So, let's consider this approach a little bit more.
> Thank you, :)
Ah, agreed.
I think we should check whether this page is uptodate or not.
And find_lock_page() will check value of 'mapping',
so we do not check here.
Anyway, I will send patch V2.
Thanks for your review. :)
>
> > > + memcpy(page_address(npage), page_address(page), PAGE_CACHE_SIZE);
> > > +
> > > + SetPageUptodate(npage);
> > > + f2fs_put_page(npage, 1);
> > > +
> > > + return;
> > > +}
> > > +
> > > int restore_node_summary(struct f2fs_sb_info *sbi,
> > > unsigned int segno, struct f2fs_summary_block *sum)
> > > {
> > > @@ -1633,6 +1661,8 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > > sum_entry->version = 0;
> > > sum_entry->ofs_in_node = 0;
> > > sum_entry++;
> > > + f2fs_cache_node_page(sbi, page,
> > > + le32_to_cpu(rn->footer.nid));
> > > } else {
> > > err = -EIO;
> > > }
> > > --
> > > 1.7.9.5
> > >
> > >
> > > --
> > > Sponsored by Intel(R) XDK
> > > Develop, test and display web and hybrid apps with a single code base.
> > > Download it for free now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631=/4140/ostg.clktrk
> > > ___
> > > Linux-f2fs-devel mailing list
> > > linux-f2fs-de...@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Jaegeuk Kim
> Samsung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
