Re: [PATCH 1/5] drivers: net: usb: rtl8150: bug fixing and cleanup
On Sun, 19 May 2013, Francois Romieu wrote: > Which one ? > - share it through the kernel or with userspace > - personal choice .c split It is obviously not the former. I think that in general constant and other definitions (in their majority) should be in a header file. I definitely like this way better. Perhaps in this particular case my patch is a bit of an overkill as the code lines aren't that many. If the consensus is in this direction i'll revert this part of the series. > I don't mind the later even if it does not exactly apply to a > WIP driver. I'd still avoid future copycat followers though. This isn't WIP anymore as the W(ork) part is missing. After so many quiet years i assume the experimental tag should be removed. > The rtl8150.h file is created in patch #2. This is patch #1. > > So... So first apply patch #1 and then patch #2. However, if it is required for the driver to be in build-able form after applying any single patch i'll coalesce #1 and #2 before next submission. David? Petko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
On 05/20/2013 02:47 PM, Borislav Petkov wrote: > On Mon, May 20, 2013 at 02:23:37PM +0800, Michael Wang wrote: >> On 05/20/2013 12:50 PM, Borislav Petkov wrote: >>> On Mon, May 20, 2013 at 11:16:33AM +0800, Michael Wang wrote: I suppose the reason is that the cpu we passed to mod_delayed_work_on() has a chance to become offline before we disabled irq, what about check it before send resched ipi? like: >>> >>> I think this is only addressing the symptoms - what we should be doing >>> instead is asking ourselves why are we even scheduling work on a cpu if >>> the machine goes offline? >>> >>> I don't know though who should be responsible for killing all that >>> work - the workqueue itself or the guy who created it, i.e. cpufreq >>> governor... >> >> So there are two questions here: >> 1. Is gov_queue_work() want to queue the work on offline cpu? >> 2. Is mod_delayed_work_on() allow offline cpu? >> >> I guess both should be false? > > Well, if we don't allow queueing work on a cpu which goes offline, i.e. > #2, the problem should be solved. I've take a look at the usage of queue_delayed_work_on() and mod_delayed_work_on(), mostly passed this_cpu, or those in online mask, I think offline cpu is not by designed. Besides, the cpu gov_queue_work() is using 'policy->cpus' which seems to be updated during UP DOWN notify, I think they are supposed to be online. But we need expert in cpufreq to confirm all these... Regards, Michael Wang > > Tejun? > > Here are the splats: http://marc.info/?l=linux-kernel&m=136879901425951 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next] x86: bpf_jit_comp: secure bpf jit against spraying attacks
From: Eric Dumazet Date: Fri, 17 May 2013 19:37:03 -0700 > From: Eric Dumazet > > hpa bringed into my attention some security related issues > with BPF JIT on x86. > > This patch makes sure the bpf generated code is marked read only, > as other kernel text sections. > > It also splits the unused space (we vmalloc() and only use a fraction of > the page) in two parts, so that the generated bpf code not starts at a > known offset in the page, but a pseudo random one. > > Refs: > http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html > > Reported-by: H. Peter Anvin > Signed-off-by: Eric Dumazet 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/
Re: [PATCH net-next] x86: bpf_jit_comp: secure bpf jit against spraying attacks
From: Daniel Borkmann Date: Sun, 19 May 2013 19:02:46 +0200 > Probably other archs could later on follow-up with setting to > read-only, too. Only s390 and x86 support this facility. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [lm-sensors] [PATCH] MAINTAINERS: Add myself as maintainer for LM95234 and TMP401 drivers
On Sun, 19 May 2013 20:48:35 -0700, Guenter Roeck wrote: > I wrote the LM95234 driver and extended the TMP401 driver substantially, > and I have hardware to test both, so it makes sense to explicitly > maintain them. > > Signed-off-by: Guenter Roeck > --- > MAINTAINERS | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3d7782b..f0f3d20 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4976,6 +4976,13 @@ S: Maintained > F: Documentation/hwmon/lm90 > F: drivers/hwmon/lm90.c > > +LM95234 HARDWARE MONITOR DRIVER > +M: Guenter Roeck > +L: lm-sens...@lm-sensors.org > +S: Maintained > +F: Documentation/hwmon/lm95234 > +F: drivers/hwmon/lm95234.c > + > LME2510 MEDIA DRIVER > M: Malcolm Priestley > L: linux-me...@vger.kernel.org > @@ -8182,6 +8189,13 @@ F: drivers/mmc/host/sh_mobile_sdhi.c > F: include/linux/mmc/tmio.h > F: include/linux/mmc/sh_mobile_sdhi.h > > +TMP401 HARDWARE MONITOR DRIVER > +M: Guenter Roeck > +L: lm-sens...@lm-sensors.org > +S: Maintained > +F: Documentation/hwmon/tmp401 > +F: drivers/hwmon/tmp401.c > + > TMPFS (SHMEM FILESYSTEM) > M: Hugh Dickins > L: linux...@kvack.org Acked-by: Jean Delvare -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 3/3] spi: s3c64xx: Added support for exynos5440 spi
From: Girish K S
This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.
Signed-off-by: Girish K S
---
drivers/spi/spi-s3c64xx.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index eaf9e1c..bd43888 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1608,6 +1608,15 @@ static struct s3c64xx_spi_port_config
exynos4_spi_port_config = {
.clk_from_cmu = true,
};
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+ .fifo_lvl_mask = { 0x1ff },
+ .rx_lvl_offset = 15,
+ .tx_st_done = 25,
+ .high_speed = true,
+ .clk_from_cmu = true,
+ .quirks = S3C64XX_SPI_QUIRK_POLL,
+};
+
static struct platform_device_id s3c64xx_spi_driver_ids[] = {
{
.name = "s3c2443-spi",
@@ -1636,6 +1645,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] =
{
{ .compatible = "samsung,exynos4210-spi",
.data = (void *)&exynos4_spi_port_config,
},
+ { .compatible = "samsung,exynos5440-spi",
+ .data = (void *)&exynos5440_spi_port_config,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/6] ARM: spear: use the core cpu hotplug functions
Please write spear as SPEAr.
On 20 May 2013 12:03, Sanjay Singh Rawat wrote:
> Generic arm cpu hotplug related functions are moved to core hotplug code,
> remove the functions from the platform code.
>
> Signed-off-by: Sanjay Singh Rawat
> ---
> arch/arm/mach-spear/hotplug.c | 37 +
> 1 file changed, 1 insertion(+), 36 deletions(-)
>
> diff --git a/arch/arm/mach-spear/hotplug.c b/arch/arm/mach-spear/hotplug.c
> index d97749c..988a9a6 100644
> --- a/arch/arm/mach-spear/hotplug.c
> +++ b/arch/arm/mach-spear/hotplug.c
> @@ -15,42 +15,7 @@
> #include
> #include
> #include
> -
> -static inline void cpu_enter_lowpower(void)
> -{
> - unsigned int v;
> -
> - asm volatile(
> - " mcr p15, 0, %1, c7, c5, 0\n"
> - " dsb\n"
> - /*
> -* Turn off coherency
> -*/
> - " mrc p15, 0, %0, c1, c0, 1\n"
> - " bic %0, %0, #0x20\n"
> - " mcr p15, 0, %0, c1, c0, 1\n"
> - " mrc p15, 0, %0, c1, c0, 0\n"
> - " bic %0, %0, %2\n"
> - " mcr p15, 0, %0, c1, c0, 0\n"
> - : "=&r" (v)
> - : "r" (0), "Ir" (CR_C)
> - : "cc", "memory");
> -}
> -
> -static inline void cpu_leave_lowpower(void)
> -{
> - unsigned int v;
> -
> - asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
> - " orr %0, %0, %1\n"
> - " mcr p15, 0, %0, c1, c0, 0\n"
> - " mrc p15, 0, %0, c1, c0, 1\n"
> - " orr %0, %0, #0x20\n"
> - " mcr p15, 0, %0, c1, c0, 1\n"
> - : "=&r" (v)
> - : "Ir" (CR_C)
> - : "cc");
> -}
I am not the best at assembly code but I can see that the
two codes (here and hotplug.c) are slightly different.
How can we ensure if this patch is okay?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 2/3] spi: s3c64xx: Added provision for dedicated cs pin
From: Girish K S
The existing driver supports gpio based /cs signal.
For controller's that have one device per controller,
the slave device's /cs signal might be internally controlled
by the chip select bit of slave select register. They are not
externally asserted/deasserted using gpio pin.
This patch adds support for controllers with dedicated /cs pin.
if "cs-gpio" property doesnt exist in a spi dts node, the controller
would treat the /cs pin as dedicated.
Signed-off-by: Girish K S
---
changes in v1:
Added the missing data structure that caused the
compilation error
drivers/spi/spi-s3c64xx.c | 34 ++
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 0a80692..eaf9e1c 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -208,6 +208,7 @@ struct s3c64xx_spi_driver_data {
struct s3c64xx_spi_port_config *port_conf;
unsigned intport_id;
unsigned long gpios[4];
+ boolcs_gpio;
};
static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
@@ -570,14 +571,16 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd->tgl_spi->controller_data;
- gpio_set_value(cs->line,
- spi->mode & SPI_CS_HIGH ? 0 : 1);
+ if (sdd->cs_gpio)
+ gpio_set_value(cs->line,
+ spi->mode & SPI_CS_HIGH ? 0 : 1);
}
sdd->tgl_spi = NULL;
}
cs = spi->controller_data;
- gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+ if (sdd->cs_gpio)
+ gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
/* Start the signals */
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -709,7 +712,8 @@ static inline void disable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi == spi)
sdd->tgl_spi = NULL;
- gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+ if (sdd->cs_gpio)
+ gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
/* Quiese the signals */
writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -997,8 +1001,10 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
{
struct s3c64xx_spi_csinfo *cs;
struct device_node *slave_np, *data_np = NULL;
+ struct s3c64xx_spi_driver_data *sdd;
u32 fb_delay = 0;
+ sdd = spi_master_get_devdata(spi->master);
slave_np = spi->dev.of_node;
if (!slave_np) {
dev_err(&spi->dev, "device node not found\n");
@@ -1018,7 +1024,10 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
- cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+ /* The CS line is asserted/deasserted by the gpio pin */
+ if (sdd->cs_gpio)
+ cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
if (!gpio_is_valid(cs->line)) {
dev_err(&spi->dev, "chip select gpio is not specified or
invalid\n");
kfree(cs);
@@ -1058,7 +1067,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
return -ENODEV;
}
- if (!spi_get_ctldata(spi)) {
+ /* Request gpio only if cs line is asserted by gpio pins */
+ if (sdd->cs_gpio) {
err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
dev_name(&spi->dev));
if (err) {
@@ -1067,9 +1077,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
cs->line, err);
goto err_gpio_req;
}
- spi_set_ctldata(spi, cs);
}
+ if (!spi_get_ctldata(spi))
+ spi_set_ctldata(spi, cs);
+
sci = sdd->cntrlr_info;
spin_lock_irqsave(&sdd->lock, flags);
@@ -1147,8 +1159,10 @@ err_gpio_req:
static void s3c64xx_spi_cleanup(struct spi_device *spi)
{
struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+ struct s3c64xx_spi_driver_data *sdd;
- if (cs) {
+ sdd = spi_master_get_devdata(spi->master);
+ if (cs && sdd->cs_gpio) {
gpio_free(cs->line);
if (spi->dev.of_node)
kfree(cs);
@@ -1325,7 +1339,11 @@ static int s3c64xx_spi_probe(struct platform_device
*pdev)
sdd->cntrlr_info = sci;
sdd->pdev = pdev;
sdd->sfr_start = mem_res->start;
+ sdd->cs_gpio = false;
if (pdev->dev.of_node) {
+
[PATCH v1 1/3] spi: s3c64xx: added support for polling mode
From: Girish K S
The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.
Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.
Signed-off-by: Girish K S
---
changes in v1:
Addressed the performance issue reported by Mark Brown
caused due to this patch. The wait_for_timeout function is modified to
address this issue in dma mode.
drivers/spi/spi-s3c64xx.c | 153 ++--
1 files changed, 104 insertions(+), 49 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 5000586..0a80692 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -39,6 +39,7 @@
#endif
#define MAX_SPI_PORTS 3
+#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
/* Registers and bit-fields */
@@ -130,6 +131,7 @@
#define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
#define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
#define RXBUSY(1<<2)
#define TXBUSY(1<<3)
@@ -158,6 +160,7 @@ struct s3c64xx_spi_port_config {
int fifo_lvl_mask[MAX_SPI_PORTS];
int rx_lvl_offset;
int tx_st_done;
+ int quirks;
boolhigh_speed;
boolclk_from_cmu;
};
@@ -344,8 +347,12 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master
*spi)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
- /* Acquire DMA channels */
- while (!acquire_dma(sdd))
+ /*
+* If DMA resource was not available during
+* probe, no need to continue with dma requests
+* else Acquire DMA channels
+*/
+ while (!is_polling(sdd) && !acquire_dma(sdd))
usleep_range(1, 11000);
pm_runtime_get_sync(&sdd->pdev->dev);
@@ -358,9 +365,12 @@ static int s3c64xx_spi_unprepare_transfer(struct
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
/* Free DMA channels */
- sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
- sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
-
+ if (!is_polling(sdd)) {
+ sdd->ops->release((enum dma_ch)sdd->rx_dma.ch,
+ &s3c64xx_spi_dma_client);
+ sdd->ops->release((enum dma_ch)sdd->tx_dma.ch,
+ &s3c64xx_spi_dma_client);
+ }
pm_runtime_put(&sdd->pdev->dev);
return 0;
@@ -464,8 +474,10 @@ static int s3c64xx_spi_unprepare_transfer(struct
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
/* Free DMA channels */
- dma_release_channel(sdd->rx_dma.ch);
- dma_release_channel(sdd->tx_dma.ch);
+ if (!is_polling(sdd)) {
+ dma_release_channel(sdd->rx_dma.ch);
+ dma_release_channel(sdd->tx_dma.ch);
+ }
pm_runtime_put(&sdd->pdev->dev);
return 0;
@@ -566,6 +578,30 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd,
cs = spi->controller_data;
gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+ /* Start the signals */
+ writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+}
+
+static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+ int timeout_ms)
+{
+ void __iomem *regs = sdd->regs;
+ unsigned long val = 1;
+ u32 status;
+
+ /* max fifo depth available */
+ u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
+
+ if (timeout_ms)
+ val = msecs_to_loops(timeout_ms);
+
+ do {
+ status = readl(regs + S3C64XX_SPI_STATUS);
+ } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
+
+ /* return the actual received data length */
+ return RX_FIFO_LVL(status, sdd);
}
static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -590,20 +626,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data
*sdd,
} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
}
- if (!val)
- return -EIO;
-
if (dma_mode) {
u32 status;
/*
+* If the previous xfer was completed within timeout, then
+* proceed further else return -EIO.
* DmaTx returns after simply writing data in the FIFO,
* w/o waiting for real transmission on the bus to finish.
* DmaRx returns only after Dma read data from FIFO which
* needs bus transmission to finish, so we don't worry if
* Xfer
[PATCH v1 0/3] Polling support for s3c64xx spi controller
This patch series adds support for the polling mode only. Also 2nd patch in the series adds support for dedicated cs pin. After Thomas's patch for using default gpio is merged(commit id: 00ab539), one of the patch in this series is dropped and new series is generated. Girish K S (3): spi: s3c64xx: added support for polling mode spi: s3c64xx: Added provision for dedicated cs pin spi: s3c64xx: Added support for exynos5440 spi drivers/spi/spi-s3c64xx.c | 197 - 1 files changed, 140 insertions(+), 57 deletions(-) -- 1.7.5.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/2] net/9p: Make 9P2000.L the default protocol for 9p file system
From: "Aneesh Kumar K.V" If we dont' specify a protocol version default to 9P2000.L. 9P2000.L have better support for posix semantic and is where all the recent development is happening. Signed-off-by: Aneesh Kumar K.V --- net/9p/client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/9p/client.c b/net/9p/client.c index 8eb7542..812a4cd 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -127,7 +127,7 @@ static int parse_opts(char *opts, struct p9_client *clnt) char *s; int ret = 0; - clnt->proto_version = p9_proto_2000u; + clnt->proto_version = p9_proto_2000L; clnt->msize = 8192; if (!opts) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] net/9p: Use virtio transpart as the default transport
From: "Aneesh Kumar K.V"
Make the default 9p experience better by defaulting to virtio transport if
present.
These days most of the users are using 9p in a virtualized setup
Signed-off-by: Aneesh Kumar K.V
---
net/9p/client.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/9p/client.c b/net/9p/client.c
index 812a4cd..5e94dab 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -1015,6 +1015,9 @@ struct p9_client *p9_client_create(const char *dev_name,
char *options)
goto destroy_tagpool;
if (!clnt->trans_mod)
+ clnt->trans_mod = v9fs_get_trans_by_name("virtio");
+
+ if (!clnt->trans_mod)
clnt->trans_mod = v9fs_get_default_trans();
if (clnt->trans_mod == NULL) {
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: kernel: compiling issue, need 'EXPORT_SYMBOL_GPL(read_current_timer)'
Need 'EXPORT_SYMBOL_GPL(read_current_timer)' if build with allmodconfig.
The related error:
ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
Signed-off-by: Chen Gang
---
arch/arm64/kernel/time.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index a551f88..7fcba80 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -73,6 +73,7 @@ int read_current_timer(unsigned long *timer_value)
*timer_value = arch_timer_read_counter();
return 0;
}
+EXPORT_SYMBOL_GPL(read_current_timer);
void __init time_init(void)
{
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] 6lowpan: Fix fragmentation with link-local compressed addresses
Hi David, I will try to figure out why link-layer address doesn't work on my setup. On Mon, May 20, 2013 at 12:14:48AM +0200, David Hauweele wrote: > Hello, > > There is a patch which fixes link-local address uncompression: > > http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1717 > > I came across a similar solution but didn't submit it as another patch > already existed. > This patch instead focus on fragmented packet with link-local address > compression, > which is related but a different bug. > > 2013/5/19 Alexander Aring : > > Hi David, > > > > can you use a link-layer address on the current net-next kernel? > > > > I am asking because I can't use a link-layer address currently. > > Your patch doesn't help to solve my problem with link-layer addresses. > > > > > > To your patch: > > > > We get the link-layer addresses from skb not from the allocated > > frame->skb. > > > > Here is the code: > > > > _saddr = mac_cb(skb)->sa.hwaddr; > > _daddr = mac_cb(skb)->da.hwaddr; > > > > Here is skb != frame->skb so we don't need to copy it to frame->skb->cb > > because we already the link-layer addresses from skb->cb. > > > > Is there another place in the code where we get the link-layer addresses > > from allocated "frame" structure? > > frame->skb is used to reassemble the 6lowpan packet when new fragments > are received. > This is the 'fragments assembling' switch at the beginning of > lowpan_process_data(). > It will reassemble fragments until the packet is successfully reassembled. > Once it is, skb is replaced: > > dev_kfree_skb(skb); > skb = frame->skb; > kfree(frame); > ah ok. > And the process continues as with other 6lowpan packets. > > In particular: > > _saddr = mac_cb(skb)->sa.hwaddr; > _daddr = mac_cb(skb)->da.hwaddr; > > Several lines later there are: > > err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix, > lowpan_unc_llconf[tmp], skb->data); > err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix, > lowpan_unc_llconf[tmp], skb->data); I think you mean uncompress and compress here. > > These two lines should use _saddr/_daddr instead of skb->data, which I agree with that. Regards Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
On Mon, May 20, 2013 at 02:23:37PM +0800, Michael Wang wrote: > On 05/20/2013 12:50 PM, Borislav Petkov wrote: > > On Mon, May 20, 2013 at 11:16:33AM +0800, Michael Wang wrote: > >> I suppose the reason is that the cpu we passed to > >> mod_delayed_work_on() has a chance to become offline before we > >> disabled irq, what about check it before send resched ipi? like: > > > > I think this is only addressing the symptoms - what we should be doing > > instead is asking ourselves why are we even scheduling work on a cpu if > > the machine goes offline? > > > > I don't know though who should be responsible for killing all that > > work - the workqueue itself or the guy who created it, i.e. cpufreq > > governor... > > So there are two questions here: > 1. Is gov_queue_work() want to queue the work on offline cpu? > 2. Is mod_delayed_work_on() allow offline cpu? > > I guess both should be false? Well, if we don't allow queueing work on a cpu which goes offline, i.e. #2, the problem should be solved. Tejun? Here are the splats: http://marc.info/?l=linux-kernel&m=136879901425951 -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mm: Remove duplicated call of get_pfn_range_for_nid
When calculating pages in a node,
for each zone in that node, we will have
zone_spanned_pages_in_node
--> get_pfn_range_for_nid
zone_absent_pages_in_node
--> get_pfn_range_for_nid
That is to say, we call the get_pfn_range_for_nid to get start_pfn
and end_pfn of the node for MAX_NR_ZONES * 2 times. And this is
totally unnecessary if we call the get_pfn_range_for_nid before
zone_*_pages_in_node add two extra arguments node_start_pfn
and node_end_pfn for zone_*_pages_in_node, then we can remove the
get_pfn_range_in_node in zone_*_pages_in_node.
Signed-off-by: Zhang Yanfei
---
mm/page_alloc.c | 40 +---
1 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 98cbdf6..b16cb49 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4366,13 +4366,13 @@ static void __meminit
adjust_zone_range_for_zone_movable(int nid,
*/
static unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *ignored)
{
- unsigned long node_start_pfn, node_end_pfn;
unsigned long zone_start_pfn, zone_end_pfn;
- /* Get the start and end of the node and zone */
- get_pfn_range_for_nid(nid, &node_start_pfn, &node_end_pfn);
+ /* Get the start and end of the zone */
zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
adjust_zone_range_for_zone_movable(nid, zone_type,
@@ -4427,14 +4427,14 @@ unsigned long __init absent_pages_in_range(unsigned
long start_pfn,
/* Return the number of page frames in holes in a zone on a node */
static unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *ignored)
{
unsigned long zone_low = arch_zone_lowest_possible_pfn[zone_type];
unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];
- unsigned long node_start_pfn, node_end_pfn;
unsigned long zone_start_pfn, zone_end_pfn;
- get_pfn_range_for_nid(nid, &node_start_pfn, &node_end_pfn);
zone_start_pfn = clamp(node_start_pfn, zone_low, zone_high);
zone_end_pfn = clamp(node_end_pfn, zone_low, zone_high);
@@ -4447,6 +4447,8 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
#else /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *zones_size)
{
return zones_size[zone_type];
@@ -4454,6 +4456,8 @@ static inline unsigned long __meminit
zone_spanned_pages_in_node(int nid,
static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *zholes_size)
{
if (!zholes_size)
@@ -4465,21 +4469,27 @@ static inline unsigned long __meminit
zone_absent_pages_in_node(int nid,
#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
- unsigned long *zones_size, unsigned long *zholes_size)
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
+ unsigned long *zones_size,
+ unsigned long *zholes_size)
{
unsigned long realtotalpages, totalpages = 0;
enum zone_type i;
for (i = 0; i < MAX_NR_ZONES; i++)
totalpages += zone_spanned_pages_in_node(pgdat->node_id, i,
- zones_size);
+node_start_pfn,
+node_end_pfn,
+zones_size);
pgdat->node_spanned_pages = totalpages;
realtotalpages = totalpages;
for (i = 0; i < MAX_NR_ZONES; i++)
realtotalpages -=
RE: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal zone device.
> -Original Message- > From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- > ow...@vger.kernel.org] On Behalf Of Jonghwa Lee > Sent: Saturday, May 18, 2013 3:20 PM > To: linux...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Zhang, Rui; Eduardo Valentin; Amit Dinel > Kachhap; Jonghwa Lee; MyungJoo Ham > Subject: [PATCH 1/3] Thermal: core: Ask .get_trip_temp() to register thermal > zone device. > > This patch adds a requirement needing .get_trip_temp() callback > function for registering thermal zone device. This function is > used when thermal zone is updated and essential where thermal core > handles thermal trip based only polling way not hw interrupt. Nice catch. Looks fine, Acked-by: Durgadoss R Thanks, Durga > > Signed-off-by: Jonghwa Lee > Signed-off-by: MyungJoo Ham > --- > drivers/thermal/thermal_core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_core.c > b/drivers/thermal/thermal_core.c > index d755440..f753f48 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1624,7 +1624,7 @@ struct thermal_zone_device > *thermal_zone_device_register(const char *type, > if (!ops || !ops->get_temp) > return ERR_PTR(-EINVAL); > > - if (trips > 0 && !ops->get_trip_type) > + if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp)) > return ERR_PTR(-EINVAL); > > tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL); > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: exynos_adc: fix wrong structure extration in suspend and resume
The exynos_adc device structure was wrongly extracted from the dev*
correcting the same.
Using the regular conversion of
struct device* -> struct platform_device* -> struct exynos_adc* seems wrong.
Instead we should be doing
struct device* -> struct iio_dev* -> struct exynos_adc*
Signed-off-by: Naveen Krishna Chatradhi
---
drivers/iio/adc/exynos_adc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index a6c4df5..2347df5 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -403,8 +403,8 @@ static int exynos_adc_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int exynos_adc_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos_adc *info = platform_get_drvdata(pdev);
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct exynos_adc *info = iio_priv(indio_dev);
u32 con;
if (info->version == ADC_V2) {
@@ -426,8 +426,8 @@ static int exynos_adc_suspend(struct device *dev)
static int exynos_adc_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos_adc *info = platform_get_drvdata(pdev);
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct exynos_adc *info = iio_priv(indio_dev);
int ret;
ret = regulator_enable(info->vdd);
--
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/
Re: [PATCH v2, part 1 8/9] PCI: make PCI host bridge/bus creating and destroying logic symmetric
On 05/14/2013 12:08 AM, Jiang Liu wrote:
> This patch makes PCI host bridge/bus creating and destroying logic
> symmetric by using device_initialize()/device_add()/device_del()/put_device()
> pairs as discussed in thread at:
> http://comments.gmane.org/gmane.linux.kernel.pci/22073
>
> It also fixes a bug in error recovery path in pci_create_root_bus()
> which may kfree() an in-use host bridge object.
>
> Signed-off-by: Jiang Liu
> Cc: Yinghai Lu
> ---
> drivers/pci/probe.c | 84
> +++-
> drivers/pci/remove.c | 3 +-
> 2 files changed, 39 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bc075a3..a2617c2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -451,7 +451,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
> }
> }
>
> -static struct pci_bus * pci_alloc_bus(void)
> +static struct pci_bus *pci_alloc_bus(struct pci_ops *ops, void *sd, int bus)
> {
> struct pci_bus *b;
>
> @@ -464,10 +464,32 @@ static struct pci_bus * pci_alloc_bus(void)
> INIT_LIST_HEAD(&b->resources);
> b->max_bus_speed = PCI_SPEED_UNKNOWN;
> b->cur_bus_speed = PCI_SPEED_UNKNOWN;
> + b->sysdata = sd;
> + b->ops = ops;
> + b->number = bus;
> + b->busn_res.start = bus;
> + b->busn_res.end = 0xff;
> + b->busn_res.flags = IORESOURCE_BUS;
> + b->dev.class = &pcibus_class;
> + dev_set_name(&b->dev, "%04x:%02x", pci_domain_nr(b), bus);
> + device_initialize(&b->dev);
> }
> +
> return b;
> }
>
> +static void pci_release_host_bridge_dev(struct device *dev)
> +{
> + struct pci_host_bridge *bridge = to_pci_host_bridge(dev);
> +
> + if (bridge->release_fn)
> + bridge->release_fn(bridge);
> +
> + pci_free_resource_list(&bridge->windows);
> +
> + kfree(bridge);
> +}
> +
> static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
> {
> struct pci_host_bridge *bridge;
> @@ -476,6 +498,10 @@ static struct pci_host_bridge
> *pci_alloc_host_bridge(struct pci_bus *b)
> if (bridge) {
> INIT_LIST_HEAD(&bridge->windows);
> bridge->bus = b;
> + bridge->dev.release = pci_release_host_bridge_dev;
> + dev_set_name(&bridge->dev, "pci%04x:%02x",
> + pci_domain_nr(b), b->number);
> + device_initialize(&bridge->dev);
> }
>
> return bridge;
> @@ -628,28 +654,13 @@ static struct pci_bus *pci_alloc_child_bus(struct
> pci_bus *parent,
> /*
>* Allocate a new bus, and inherit stuff from the parent..
>*/
> - child = pci_alloc_bus();
> + child = pci_alloc_bus(parent->ops, parent->sysdata, busnr);
> if (!child)
> return NULL;
>
> child->parent = parent;
> - child->ops = parent->ops;
> - child->sysdata = parent->sysdata;
> child->bus_flags = parent->bus_flags;
> -
> - /* initialize some portions of the bus device, but don't register it
> - * now as the parent is not properly set up yet.
> - */
> - child->dev.class = &pcibus_class;
> - dev_set_name(&child->dev, "%04x:%02x", pci_domain_nr(child), busnr);
> -
> - /*
> - * Set up the primary, secondary and subordinate
> - * bus numbers.
> - */
> - child->number = child->busn_res.start = busnr;
> child->primary = parent->busn_res.start;
> - child->busn_res.end = 0xff;
>
> if (!bridge) {
> child->dev.parent = parent->bridge;
> @@ -670,7 +681,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
> *parent,
> bridge->subordinate = child;
>
> add_dev:
> - ret = device_register(&child->dev);
> + ret = device_add(&child->dev);
> WARN_ON(ret < 0);
>
> pcibios_add_bus(child);
> @@ -1190,18 +1201,6 @@ int pci_cfg_space_size(struct pci_dev *dev)
> return PCI_CFG_SPACE_SIZE;
> }
>
> -static void pci_release_bus_bridge_dev(struct device *dev)
> -{
> - struct pci_host_bridge *bridge = to_pci_host_bridge(dev);
> -
> - if (bridge->release_fn)
> - bridge->release_fn(bridge);
> -
> - pci_free_resource_list(&bridge->windows);
> -
> - kfree(bridge);
> -}
> -
> struct pci_dev *pci_alloc_dev(struct pci_bus *bus)
> {
> struct pci_dev *dev;
> @@ -1688,13 +1687,10 @@ struct pci_bus *pci_create_root_bus(struct device
> *parent, int bus,
> char bus_addr[64];
> char *fmt;
>
> - b = pci_alloc_bus();
> + b = pci_alloc_bus(ops, sysdata, bus);
> if (!b)
> return NULL;
>
> - b->sysdata = sysdata;
> - b->ops = ops;
> - b->number = b->busn_res.start = bus;
> b2 = pci_find_bus(pci_domain_nr(b), bus);
> if (b2) {
> /* If we already got to this bus through a different bridge,
> ignore it
[RFC PATCH 4/6] ARM: spear: use the core cpu hotplug functions
Generic arm cpu hotplug related functions are moved to core hotplug code,
remove the functions from the platform code.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/mach-spear/hotplug.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
diff --git a/arch/arm/mach-spear/hotplug.c b/arch/arm/mach-spear/hotplug.c
index d97749c..988a9a6 100644
--- a/arch/arm/mach-spear/hotplug.c
+++ b/arch/arm/mach-spear/hotplug.c
@@ -15,42 +15,7 @@
#include
#include
#include
-
-static inline void cpu_enter_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- " mcr p15, 0, %1, c7, c5, 0\n"
- " dsb\n"
- /*
-* Turn off coherency
-*/
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, #0x20\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C)
- : "cc", "memory");
-}
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile("mrc p15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, #0x20\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C)
- : "cc");
-}
+#include
static inline void spear13xx_do_lowpower(unsigned int cpu, int *spurious)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/6] ARM: imx: use the core cpu hotplug functions
Generic arm cpu hotplug related functions are moved to core hotplug code,
remove the functions from the platform code.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/mach-imx/hotplug.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/arch/arm/mach-imx/hotplug.c b/arch/arm/mach-imx/hotplug.c
index 3daf1ed..280c6f3 100644
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -14,30 +14,10 @@
#include
#include
#include
+#include
#include "common.h"
-static inline void cpu_enter_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mcrp15, 0, %1, c7, c5, 0\n"
- " mcr p15, 0, %1, c7, c10, 4\n"
- /*
-* Turn off coherency
-*/
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %3\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
/*
* platform-specific code to shutdown a CPU
*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 5/6] ARM: vexpress: use the core cpu hotplug functions
Generic arm cpu hotplug related functions are moved to core hotplug code,
remove the functions from the platform code.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/mach-vexpress/hotplug.c | 38 +-
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/arch/arm/mach-vexpress/hotplug.c b/arch/arm/mach-vexpress/hotplug.c
index f0ce6b8..cca1361 100644
--- a/arch/arm/mach-vexpress/hotplug.c
+++ b/arch/arm/mach-vexpress/hotplug.c
@@ -14,43 +14,7 @@
#include
#include
-
-static inline void cpu_enter_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mcrp15, 0, %1, c7, c5, 0\n"
- " mcr p15, 0, %1, c7, c10, 4\n"
- /*
-* Turn off coherency
-*/
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %3\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mrcp15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
+#include
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 6/6] ARM: EXYNOS: use the core cpu hotplug functions
Generic arm cpu hotplug related functions are moved to core hotplug code,
Exynos-4 is having Cortex-A9, remove the functions from the platform code.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/mach-exynos/hotplug.c | 40 ++--
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index af90cfa..3489760 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -21,30 +21,10 @@
#include
#include
+#include
#include "common.h"
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
- " mcr p15, 0, %1, c7, c5, 0\n"
- " mcr p15, 0, %1, c7, c10, 4\n"
- /*
-* Turn off coherency
-*/
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %3\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
static inline void cpu_enter_lowpower_a15(void)
{
unsigned int v;
@@ -74,22 +54,6 @@ static inline void cpu_enter_lowpower_a15(void)
dsb();
}
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mrcp15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
for (;;) {
@@ -144,7 +108,7 @@ void __ref exynos_cpu_die(unsigned int cpu)
if ((primary_part & 0xfff0) == 0xc0f0)
cpu_enter_lowpower_a15();
else
- cpu_enter_lowpower_a9();
+ cpu_enter_lowpower();
platform_do_lowpower(cpu, &spurious);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/6] ARM: RealView: use the core cpu hotplug functions
Generic arm cpu hotplug related functions are moved to core hotplug code,
remove the functions from the platform code.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/mach-realview/hotplug.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
diff --git a/arch/arm/mach-realview/hotplug.c b/arch/arm/mach-realview/hotplug.c
index ac22dd4..a48cc71 100644
--- a/arch/arm/mach-realview/hotplug.c
+++ b/arch/arm/mach-realview/hotplug.c
@@ -14,42 +14,7 @@
#include
#include
-
-static inline void cpu_enter_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- " mcr p15, 0, %1, c7, c5, 0\n"
- " mcr p15, 0, %1, c7, c10, 4\n"
- /*
-* Turn off coherency
-*/
- " mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, #0x20\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- " mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- : "=&r" (v)
- : "r" (0), "Ir" (CR_C)
- : "cc");
-}
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile( "mrcp15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, #0x20\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=&r" (v)
- : "Ir" (CR_C)
- : "cc");
-}
+#include
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/6] ARM: cpuhotplug: move common functions to core
Various SoCs with arm processors define their own platform hotplug related functions. These functions can be defined as part of the core cpu hotplug functions, this will avoid the duplication. This patchset is intended to address this issue. This patchset covers arm-Cortex-A9 of exynos, imx, realview, spear and vexpress SoCs. Not having h/w, the patch is not tested. Sanjay Singh Rawat (6): ARM: cpuhotplug: move common hotplug related functions to core ARM: imx: use the core cpu hotplug functions ARM: RealView: use the core cpu hotplug functions ARM: spear: use the core cpu hotplug functions ARM: vexpress: use the core cpu hotplug functions ARM: EXYNOS: use the core cpu hotplug functions arch/arm/include/asm/hotplug.h | 24 ++ arch/arm/kernel/Makefile |1 + arch/arm/kernel/cpuhotplug.c | 64 ++ arch/arm/mach-exynos/hotplug.c | 40 ++-- arch/arm/mach-imx/hotplug.c | 22 + arch/arm/mach-realview/hotplug.c | 37 +- arch/arm/mach-spear/hotplug.c| 37 +- arch/arm/mach-vexpress/hotplug.c | 38 +- 8 files changed, 95 insertions(+), 168 deletions(-) create mode 100644 arch/arm/include/asm/hotplug.h create mode 100644 arch/arm/kernel/cpuhotplug.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/6] ARM: cpuhotplug: move common hotplug related functions to core
Add function which prepare arm processors to enter the low power for hotplug
functionality and handle the return path.
Signed-off-by: Sanjay Singh Rawat
---
arch/arm/include/asm/hotplug.h | 24 +++
arch/arm/kernel/Makefile |1 +
arch/arm/kernel/cpuhotplug.c | 64
3 files changed, 89 insertions(+)
create mode 100644 arch/arm/include/asm/hotplug.h
create mode 100644 arch/arm/kernel/cpuhotplug.c
diff --git a/arch/arm/include/asm/hotplug.h b/arch/arm/include/asm/hotplug.h
new file mode 100644
index 000..ae80f0e
--- /dev/null
+++ b/arch/arm/include/asm/hotplug.h
@@ -0,0 +1,24 @@
+/*
+ * arch/arm/include/asm/hotplug.h
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+extern inline void cpu_enter_lowpower(void);
+extern inline void cpu_leave_lowpower(void);
+
+#else
+static inline void cpu_enter_lowpower(void)
+{
+ return -ENODEV;
+}
+static inline void cpu_leave_lowpower(void)
+{
+ return -ENODEV;
+}
+
+#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..9bd370b 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
obj-$(CONFIG_ARM_CPU_SUSPEND) += sleep.o suspend.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
+obj-$(CONFIG_HOTPLUG_CPU) += cpuhotplug.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arch_timer.o
diff --git a/arch/arm/kernel/cpuhotplug.c b/arch/arm/kernel/cpuhotplug.c
new file mode 100644
index 000..8651b96
--- /dev/null
+++ b/arch/arm/kernel/cpuhotplug.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2002 ARM Ltd.
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+/*
+ * For Cortex-A9 processor
+ */
+static inline void ca9_enter_lowpower(void)
+{
+ unsigned int v;
+
+ asm volatile(
+ " mcr p15, 0, %1, c7, c5, 0\n"
+ " mcr p15, 0, %1, c7, c10, 4\n"
+ /*
+* Turn off coherency
+*/
+ " mrc p15, 0, %0, c1, c0, 1\n"
+ " bic %0, %0, %3\n"
+ " mcr p15, 0, %0, c1, c0, 1\n"
+ " mrc p15, 0, %0, c1, c0, 0\n"
+ " bic %0, %0, %2\n"
+ " mcr p15, 0, %0, c1, c0, 0\n"
+ : "=&r" (v)
+ : "r" (0), "Ir" (CR_C), "Ir" (0x40)
+ : "cc");
+}
+
+inline void cpu_leave_lowpower(void)
+{
+ unsigned int v;
+
+ asm volatile(
+ "mrcp15, 0, %0, c1, c0, 0\n"
+ " orr %0, %0, %1\n"
+ " mcr p15, 0, %0, c1, c0, 0\n"
+ " mrc p15, 0, %0, c1, c0, 1\n"
+ " orr %0, %0, %2\n"
+ " mcr p15, 0, %0, c1, c0, 1\n"
+ : "=&r" (v)
+ : "Ir" (CR_C), "Ir" (0x40)
+ : "cc");
+}
+
+void cpu_enter_lowpower(void)
+{
+ int id = 0;
+
+ /* check the cpuid */
+ asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(id) : : "cc");
+
+ if ((id & 0x) == 0x411fc090)
+ ca9_enter_lowpower();
+ else
+ pr_warn(KERN_WARNING "Unknown CPU type\n");
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
On 05/20/2013 12:50 PM, Borislav Petkov wrote: > On Mon, May 20, 2013 at 11:16:33AM +0800, Michael Wang wrote: >> I suppose the reason is that the cpu we passed to >> mod_delayed_work_on() has a chance to become offline before we >> disabled irq, what about check it before send resched ipi? like: > > I think this is only addressing the symptoms - what we should be doing > instead is asking ourselves why are we even scheduling work on a cpu if > the machine goes offline? > > I don't know though who should be responsible for killing all that > work - the workqueue itself or the guy who created it, i.e. cpufreq > governor... So there are two questions here: 1. Is gov_queue_work() want to queue the work on offline cpu? 2. Is mod_delayed_work_on() allow offline cpu? I guess both should be false? Regards, Michael Wang > > Hmmm. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/10 fix] mtd: get the ECC info from the Extended Parameter Page
Hi Huang, Vikram,
On 05/19/2013 07:08 PM, Huang Shijie wrote:
...
+ /*
+* From section 5.7.2.2, we know that the Extened Param Page is valid
+* when two or more bytes of the signatrue are valid.
s/signatrue/signature
+* So we only check the first two bytes here.
+*/
+ if (strncmp(ep->sig, "EP", 2)) {
+ pr_debug("The signatrue is invalid.\n");
Ditto.
+ goto ext_out;
+ }
What's the reasoning about this whole "only check 2 bytes" thing? I
understand that this is technically what spec *says* (although you're
actually not checking the other 5 combinations that are valid: 'ExPx'
'ExxS' 'xPPx' 'xPxS' 'xxPS'). But *why* does the spec say this? To
tolerate errors or to tolerate changes in the spec (e.g., new types of
parameter pages that say 'QPPS' [1], for instance)? The former doesn't
really sound plausible, since if we're going to have 2 whole bytes of
errors in the signature, then we really shouldn't trust the whole
(extended) parameter page. And the latter doesn't really make sense to
me; any future backwards-compatible modifications should just use the
same signature string.
Anyway, my point is that there has to be some logic to strictly
following the letter of the specification. Shortening the check to just
the 2-byte "EP" string does not actually cover *exactly* what the spec
might allow (e.g., it doesn't allow "QPPS" [1]). But it also doesn't
make any sense why we want to check anything besides "EPPS". So my
natural inclination is to be strict in what we accept (i.e., exactly the
"EPPS" string) until we find a reason otherwise.
Or, if you're gonna pull the strict compliance card, check all 6
combinations, not just 1 of them.
Brian
[1] This is a totally made-up example. I do not understand at all why
ONFI would allow anything besides exactly "EPPS".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: max98090: request IRQF_ONESHOT interrupt
request_threaded_irq() rejects calls which both do not specify a handler
(indicating that the primary IRQ handler should be used) and do not set
IRQF_ONESHOT because the combination is unsafe with level-triggered
interrupts. It is safe in this case, though, since max98090 IRQs are
edge-triggered and the interrupts aren't ACK'ed until the codec's IRQ
status register is read. Because of this, an IRQF_ONESHOT interrupt
doesn't really make a difference, but request one anyway in order to make
request_threaded_irq() happy.
Signed-off-by: Andrew Bresticker
---
sound/soc/codecs/max98090.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index cbb272b..1bf96bd 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2247,7 +2247,7 @@ static int max98090_probe(struct snd_soc_codec *codec)
dev_dbg(codec->dev, "irq = %d\n", max98090->irq);
ret = request_threaded_irq(max98090->irq, NULL,
- max98090_interrupt, IRQF_TRIGGER_FALLING,
+ max98090_interrupt, IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
"max98090_interrupt", codec);
if (ret < 0) {
dev_err(codec->dev, "request_irq failed: %d\n",
--
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/
[PATCH] arm64: kernel: need extern variable 'screen_info' for related driver using.
Add the extern variable 'screen_info' according to arm32 has done.
The related error:
drivers/video/console/vgacon.c:1305: undefined reference to `screen_info'
Signed-off-by: Chen Gang
---
arch/arm64/kernel/setup.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index add6ea6..1055992 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -374,3 +374,14 @@ const struct seq_operations cpuinfo_op = {
.stop = c_stop,
.show = c_show
};
+
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
+struct screen_info screen_info = {
+ .orig_video_lines = 30,
+ .orig_video_cols= 80,
+ .orig_video_mode= 0,
+ .orig_video_ega_bx = 0,
+ .orig_video_isVGA = 1,
+ .orig_video_points = 8
+};
+#endif
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 14 May 2013 18:30, Rafael J. Wysocki wrote: > On Tuesday, May 14, 2013 09:36:42 PM Kukjin Kim wrote: >> Viresh Kumar wrote: >> > >> > On 13 May 2013 16:21, Rafael J. Wysocki wrote: >> > > That doesn't matter I suppose. I can take it, but please rebase it on >> > top >> > > of current linux-next. >> > >> > I have already done that (attached). But i wasn't sure what Kukjin wants >> > as >> > he may report conflicts again and i will ask the same question for 3.12 :) >> > >> Since this missed last time, this would be sent to upstream via samsung tree >> again. It means the conflicts should be handled by myself. >> >> Rafael, if you don't mind, let me take this into Samsung tree for v3.11. > > Sure, please go ahead. Kukjin, I hope you have already applied this for linux-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/
[PATCH] lib/mpi/mpicoder.c: looping issue, need stop when equal to zero, found by 'EXTRA_FLAGS=-W'.
For 'while' looping, need stop when 'nbytes == 0', or will cause issue.
('nbytes' is size_t which is always bigger or equal than zero).
The related warning: (with EXTRA_CFLAGS=-W)
lib/mpi/mpicoder.c:40:2: warning: comparison of unsigned expression >= 0 is
always true [-Wtype-limits]
Signed-off-by: Chen Gang
---
lib/mpi/mpicoder.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 5f9c44c..4cc6442 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -37,7 +37,7 @@ MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes)
mpi_limb_t a;
MPI val = NULL;
- while (nbytes >= 0 && buffer[0] == 0) {
+ while (nbytes > 0 && buffer[0] == 0) {
buffer++;
nbytes--;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 3.10-rc1 p-state/cpuidle panic
Hmm, divide by 0, it seems. + Dirk Brandewie. On Sun, May 19, 2013 at 01:25:41PM +0200, Tommy Apel Hansen wrote: > Hello guys, I'm getting this with the current 3.10-rc1, I've enabled the new > full-NOHZ > I'm not sure though if that has something to do with this or if something is > changed in the > p-state code. > > System : > vendor_id : GenuineIntel > cpu family : 6 > model : 45 > model name : Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz > stepping : 7 > microcode : 0x70b > cpu MHz : 1176.000 > cache size : 10240 KB > physical id : 1 > siblings : 4 > core id : 3 > cpu cores : 4 > apicid: 38 > initial apicid : 38 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp: yes > flags : [lots of stuff] > bogomips : 4800.56 > clflush size : 64 > cache_alignment : 64 > address sizes : 46 bits physical, 48 bits virtual > power management: > > crash bt: > PID: 0 TASK: 88085c585950 CPU: 5 COMMAND: "swapper/5" > #0 [88107fc83b80] machine_kexec at 8102aad6 > #1 [88107fc83bc0] crash_kexec at 810e57d0 > #2 [88107fc83c90] oops_end at 810073b8 > #3 [88107fc83cb0] do_divide_error at 810040c2 > #4 [88107fc83d50] divide_error at 81637348 > [exception RIP: intel_pstate_timer_func+1071] > RIP: 814f501f RSP: 88107fc83e08 RFLAGS: 00010246 > RAX: RBX: 8808555b9e00 RCX: 8808555b9e40 > RDX: RSI: 0064 RDI: 0001 > RBP: 025debb95955 R8: 8808555b9f70 R9: 03e0 > R10: dead00200200 R11: R12: 001877f8d1d3 > R13: 9a45ae19 R14: 001d27d3d1d8 R15: 0040 > ORIG_RAX: CS: 0010 SS: 0018 > #5 [88107fc83e00] intel_pstate_timer_func at 814f4fa2 > #6 [88107fc83e60] call_timer_fn at 8109edc3 > #7 [88107fc83e90] run_timer_softirq at 810a097e > #8 [88107fc83f10] __do_softirq at 810990f1 > #9 [88107fc83f80] irq_exit at 810993ce > #10 [88107fc83f90] smp_apic_timer_interrupt at 81026448 > #11 [88107fc83fb0] apic_timer_interrupt at 81636eca > --- --- > #12 [88085c587db8] apic_timer_interrupt at 81636eca > [exception RIP: cpuidle_enter_state+72] > RIP: 814f5978 RSP: 88085c587e68 RFLAGS: 0216 > RAX: 0001c61d RBX: 810a11e8 RCX: 0018 > RDX: 000225c17d03 RSI: 88085c587fd8 RDI: 81a12500 > RBP: 0002 R8: 0030 R9: 0001 > R10: R11: R12: 810c48dd > R13: 88085c173950 R14: 0086 R15: > ORIG_RAX: ff10 CS: 0010 SS: 0018 > #13 [88085c587eb0] cpuidle_idle_call at 814f5aca > #14 [88085c587ef0] arch_cpu_idle at 8100cef9 > #15 [88085c587f00] cpu_startup_entry at 810ce5af > > kernel config: > http://pastebin.com/AmEqQNZx > > /Tommy > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
On Mon, May 20, 2013 at 11:16:33AM +0800, Michael Wang wrote: > I suppose the reason is that the cpu we passed to > mod_delayed_work_on() has a chance to become offline before we > disabled irq, what about check it before send resched ipi? like: I think this is only addressing the symptoms - what we should be doing instead is asking ourselves why are we even scheduling work on a cpu if the machine goes offline? I don't know though who should be responsible for killing all that work - the workqueue itself or the guy who created it, i.e. cpufreq governor... Hmmm. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for May 20
Hi all, Changes since 20130517: The usb.current tree gained a conflict against Linus' tree. The rr-fixes tree gained a build failure so I used the version from next-20130515. The akpm tree gained conflicts against Linus' and the net-next tree. 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. 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. We are up to 226 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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 Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (343cd4f Merge tag 'dm-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm) Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (f66ba56 package: Makefile: unbreak binrpm-pkg target) Merging arc-current/for-curr (81ec684 ARC: [mm] change semantics of __sync_icache_dcache() to inv d$ lines) Merging arm-current/fixes (6eabb33 ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value) Merging m68k-current/for-linus (f722406 Linux 3.10-rc1) Merging powerpc-merge/merge (e34166a powerpc: Set show_unhandled_signals to 1 by default) Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc) Merging net/master (ff0102e net: irda: using kzalloc() instead of kmalloc() to avoid strncpy() issue.) Merging ipsec/master (da241ef Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (e6135fe ALSA: usb-audio: proc: use found syncmaxsize to determine feedback format) Merging pci-current/for-linus (3f327e3 PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check) Merging wireless/master (6bb4880 ath9k: fix draining aggregation tid buffers) Merging driver-core.current/driver-core-linus (f722406 Linux 3.10-rc1) Merging tty.current/tty-linus (f722406 Linux 3.10-rc1) Merging usb.current/usb-linus (7138143 USB: ftdi_sio: Add support for Newport CONEX motor drivers) CONFLICT (content): Merge conflict in drivers/usb/host/ohci-nxp.c Merging staging.current/staging-linus (642f2ec staging: dwc2: Fix dma-enabled platform devices using a default dma_mask) Merging char-misc.current/char-misc-linus (221ba15 Char: lp, protect LPGETSTATUS with port_mutex) Merging input-current/for-linus (f0aacea Input: wacom - add a few new styli for Cintiq series) Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks of hybid raid1/raid10 array) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (286233e crypto: caam - fix inconsistent assoc dma mapping direction) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-
RE: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
> > > >
> > > > am33xx_pinmux: pinmux@44e10800 {
> > > > pinctrl-names = "default";
> > > > - pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
> > > > + pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0
> > > > + &nandflash_pins_s0>;
> > >
> > > Why add this to the board level fallback (called pinctrl hogs, I think)?
> > > This can be part of nand node you added below so that the pinctrl will
> > > take effect when nand gets probed instead of all the time.
> >
> > Yes we should have all the pinctrl entries under the related drivers.
> > This makes it easy remux pins during runtime if needed, and also
> > allows unloading pinctrl-single.ko for development.
> >
> Yes, accepted. This has been already fixed in v3 of this patch set.
> If all fine, then please pull this for next merge..
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046712.html
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046814.html
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046710.html
>
>
> with regards, pekon
Request you to please accept | provide feedbacks on this patch series.
These are waiting acceptance since Jan-2013, and are necessary for
DT based configs for board having NAND support.
with regards, pekon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi Shengzhou/Braun,
We changed the controller init sequence to make this work. I'll submit the
patch upstream soon.
Regards,
Ramneek
-Original Message-
From: Liu Shengzhou-B36685
Sent: Monday, May 20, 2013 9:07 AM
To: Michael Braun; Mehresh Ramneek-B31383
Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
linux-...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
Subject: RE: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
Freescale P1020
Hi Braun,
At that time I had an P4080DS board which had the same issue and had been fixed
with this patch.
I didn't test it on P1020 due to the absence of P1020. I think P1020 will need
a new patch besides this one.
Later Ramneek took this issue on P1020 for more investigation.
Hello Ramneek, any update for the PHY_CLK_VALID issue?
Regards,
Shengzhou
> -Original Message-
> From: Michael Braun [mailto:michael.br...@fem.tu-ilmenau.de]
> Sent: Sunday, May 19, 2013 11:23 PM
> To: Liu Shengzhou-B36685
> Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
> Subject: Re: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884
> with Freescale P1020
>
> Hi,
>
> I've got hardware here to test with, so if there any changes to test,
> I'm willing to support.
> Meanwhile, might it be a good idea to make that check optional - i.e.
> add a module parameter or something like this around it?
>
> Regards,
> M. Braun
>
> On Thu, Apr 18, 2013 at 05:13:39PM +0200, michael-dev wrote:
> > Hi,
> >
> > thanks for the quick reply.
> >
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > I applied it, but it does not make any difference on my platform.
> >
> > Regards,
> > M. Braun
> >
> > Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
> > >Hi Braun,
> > >
> > >It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
> > >unstable, introduced by patch "EHCI: centralize controller
> > >initialization".
> > >I submitted a patch to fix it.
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > >
> > >Regards,
> > >Shengzhou
> > >
> > >
> > >>-Original Message-
> > >>From: Michael Braun [mailto:michael-...@fami-braun.de]
> > >>Sent: Wednesday, April 17, 2013 6:08 PM
> > >>To: Liu Shengzhou-B36685
> > >>Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg
> > >>Kroah-Hartman; linux-...@vger.kernel.org;
> > >>linux-kernel@vger.kernel.org
> > >>Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884
> > >>with Freescale P1020
> > >>
> > >>Hi,
> > >>
> > >>I'm running OpenWRT Kernel 3.8.3 (which already has
> > >>f66dea709cd9309b2ee9f715697818001fb518de and
> > >>5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
> > >>(QorlQ,
> > >>PPC) device.
> > >>Before updating the kernel from 3.3.0, USB host support was
> > >>working fine.
> > >>Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and
> > >>the lsusb output is empty, so USB host support is not working.
> > >>When I apply the following patch, USB host support starts working
> > >>again, so I guess
> > >>3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
> > >>Do you have an idea how to fix it more appropriately?
> > >>
> > >>Thanks,
> > >> M. Braun
> > >>
> > >>--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
> > >>+0200
> > >>+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
> > >>+0200
> > >>@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
> > >> if (!spin_event_timeout(in_be32(non_ehci +
> > >>FSL_SOC_USB_CTRL) &
> > >> PHY_CLK_VALID,
> > >>FSL_USB_PHY_CLK_TIMEOUT,
> > >>0)) {
> > >> printk(KERN_WARNING "fsl-ehci: USB PHY
> > >>clock invalid\n");
> > >>- return -EINVAL;
> > >> }
> > >> }
> > >>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
On 13 May 2013 11:34, Viresh Kumar wrote: > On 22 April 2013 12:19, Viresh Kumar wrote: >> On 9 April 2013 14:05, Viresh Kumar wrote: >>> On 5 April 2013 12:16, Viresh Kumar wrote: On 4 April 2013 18:24, Viresh Kumar wrote: > This patch moves cpufreq driver of powerpc platform to drivers/cpufreq. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Olof Johansson > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Viresh Kumar > --- > Compile Tested only. > > arch/powerpc/platforms/Kconfig | 31 > -- > arch/powerpc/platforms/pasemi/Makefile | 1 - > arch/powerpc/platforms/powermac/Makefile | 2 -- > drivers/cpufreq/Kconfig.powerpc| 26 > ++ > drivers/cpufreq/Makefile | 3 +++ > .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c | 0 > .../cpufreq/pmac32-cpufreq.c | 0 > .../cpufreq/pmac64-cpufreq.c | 0 > 8 files changed, 29 insertions(+), 34 deletions(-) > rename arch/powerpc/platforms/pasemi/cpufreq.c => > drivers/cpufreq/pasemi-cpufreq.c (100%) > rename arch/powerpc/platforms/powermac/cpufreq_32.c => > drivers/cpufreq/pmac32-cpufreq.c (100%) > rename arch/powerpc/platforms/powermac/cpufreq_64.c => > drivers/cpufreq/pmac64-cpufreq.c (100%) Hi Deepthi, Can you help testing this please? >>> >>> Ping!! >> >> Ping!! > > Hi Benjamin, > > Hope you are back from your vacations. Can you give it a try now? Ping!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
On 20 May 2013 00:13, Francesco Lavra wrote:
> On 05/17/2013 01:26 PM, Viresh Kumar wrote:
>> +EXPORT_SYMBOL(get_cpufreq_global_kobject);
>> +EXPORT_SYMBOL(put_cpufreq_global_kobject);
>
> Global symbol names should begin with a sensible prefix; in this case,
> it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject
> would be more appropriate names.
Please see if V2 looks fine. Attached too for applying.
xx--
From: Viresh Kumar
Date: Fri, 17 May 2013 16:09:09 +0530
Subject: [PATCH V2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq
directory
When we don't have any file in cpu/cpufreq directory we shouldn't create it.
Specially with the introduction of per-policy governor instance patchset, even
governors are moved to cpu/cpu*/cpufreq/governor-name directory and so this
directory is just not required.
Lets have it only when required.
Signed-off-by: Viresh Kumar
---
V1->V2: Replace: {get|put}_cpufreq_global_kobject with
cpufreq_{get|put}_global_kobject.
drivers/cpufreq/acpi-cpufreq.c | 4 ++--
drivers/cpufreq/cpufreq.c | 48 ++
drivers/cpufreq/cpufreq_governor.c | 6 +
include/linux/cpufreq.h| 4
4 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index ce28c34..ae0918d 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -947,7 +947,7 @@ static void __init acpi_cpufreq_boost_init(void)
/* We create the boost file in any case, though for systems without
* hardware support it will be read-only and hardwired to return 0.
*/
- if (sysfs_create_file(cpufreq_global_kobject, &(global_boost.attr)))
+ if (cpufreq_sysfs_create_file(&(global_boost.attr)))
pr_warn(PFX "could not register global boost sysfs file\n");
else
pr_debug("registered global boost sysfs file\n");
@@ -955,7 +955,7 @@ static void __init acpi_cpufreq_boost_init(void)
static void __exit acpi_cpufreq_boost_exit(void)
{
- sysfs_remove_file(cpufreq_global_kobject, &(global_boost.attr));
+ cpufreq_sysfs_remove_file(&(global_boost.attr));
if (msrs) {
unregister_cpu_notifier(&boost_nb);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e3d7112..74a1a60 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -678,9 +678,6 @@ static struct attribute *default_attrs[] = {
NULL
};
-struct kobject *cpufreq_global_kobject;
-EXPORT_SYMBOL(cpufreq_global_kobject);
-
#define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
#define to_attr(a) container_of(a, struct freq_attr, attr)
@@ -751,6 +748,49 @@ static struct kobj_type ktype_cpufreq = {
.release= cpufreq_sysfs_release,
};
+struct kobject *cpufreq_global_kobject;
+EXPORT_SYMBOL(cpufreq_global_kobject);
+
+static int cpufreq_global_kobject_usage;
+
+int cpufreq_get_global_kobject(void)
+{
+ if (!cpufreq_global_kobject_usage++)
+ return kobject_add(cpufreq_global_kobject,
+ &cpu_subsys.dev_root->kobj, "%s", "cpufreq");
+
+ return 0;
+}
+EXPORT_SYMBOL(cpufreq_get_global_kobject);
+
+void cpufreq_put_global_kobject(void)
+{
+ if (!--cpufreq_global_kobject_usage)
+ kobject_del(cpufreq_global_kobject);
+}
+EXPORT_SYMBOL(cpufreq_put_global_kobject);
+
+int cpufreq_sysfs_create_file(const struct attribute *attr)
+{
+ int ret = cpufreq_get_global_kobject();
+
+ if (!ret) {
+ ret = sysfs_create_file(cpufreq_global_kobject, attr);
+ if (ret)
+ cpufreq_put_global_kobject();
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(cpufreq_sysfs_create_file);
+
+void cpufreq_sysfs_remove_file(const struct attribute *attr)
+{
+ sysfs_remove_file(cpufreq_global_kobject, attr);
+ cpufreq_put_global_kobject();
+}
+EXPORT_SYMBOL(cpufreq_sysfs_remove_file);
+
/* symlink affected CPUs */
static int cpufreq_add_dev_symlink(unsigned int cpu,
struct cpufreq_policy *policy)
@@ -2022,7 +2062,7 @@ static int __init cpufreq_core_init(void)
init_rwsem(&per_cpu(cpu_policy_rwsem, cpu));
}
- cpufreq_global_kobject = kobject_create_and_add("cpufreq",
&cpu_subsys.dev_root->kobj);
+ cpufreq_global_kobject = kobject_create();
BUG_ON(!cpufreq_global_kobject);
register_syscore_ops(&cpufreq_syscore_ops);
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index b6cfd55..7532570 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -231,6 +231,9 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
return rc;
}
+ if (!have_governor_
[PATCH] arm64: compiling issue for allmodconfig, need "asm/parport.h" by "drivers/parport/parport_pc.c"
Need add the default file in 'asm/Kbuild' just like arm has done. The build command is: make EXTRA_CFLAGS=-W ARCH=arm64 allmodconfig make EXTRA_CFLAGS=-W ARCH=arm64 menuconfig set "aarch64-linux-gnu-" as cross compiling prefix. make EXTRA_CFLAGS=-W ARCH=arm64 The related error: drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory Signed-off-by: Chen Gang --- arch/arm64/include/asm/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 79a642d..9005e81 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -25,6 +25,7 @@ generic-y += local64.h generic-y += mman.h generic-y += msgbuf.h generic-y += mutex.h +generic-y += parport.h generic-y += pci.h generic-y += percpu.h generic-y += poll.h -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
On 20 May 2013 00:13, Francesco Lavra wrote: > On 05/17/2013 01:26 PM, Viresh Kumar wrote: >> +EXPORT_SYMBOL(get_cpufreq_global_kobject); >> +EXPORT_SYMBOL(put_cpufreq_global_kobject); > > Global symbol names should begin with a sensible prefix; in this case, > it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject > would be more appropriate names. Sure. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the usb.current tree with Linus' tree
On Mon, May 20, 2013 at 10:21:59AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb.current tree got a conflict in
> drivers/usb/host/ohci-nxp.c between commit bb522812a1a6
> ("drivers/usb/host: don't check resource with devm_ioremap_resource")
> from Linus' tree and commit b3517d5de80e ("usb: ohci: fix goto wrong tag
> in err case") from the usb.current tree.
>
> The former remove a bit of code modified by the latter, so I did that and
> can carry the fix as necessary (no action is required).
Sounds fine to me, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/net/bpf_jit_comp.c between commit 650c8496702f ("x86:
bpf_jit_comp: can call module_free() from any context") from the net-next
tree and commit "bpf: add comments explaining the schedule_work()
operation" from the akpm tree.
The former means that the latter is no longer needed, so I used the
former and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpYRzuJ6KAtU.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/sparc/net/bpf_jit_comp.c between commit 5199dfe531db ("sparc:
bpf_jit_comp: can call module_free() from any context") from the net-next
tree and commit "bpf: add comments explaining the schedule_work()
operation" from the akpm tree.
The former means that the latter is no longer reqired, so I used the
former and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpkWBo8Xsp2_.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
fs/btrfs/inode.c and fs/btrfs/volumes.c between commit 9be3395bcd4a
("Btrfs: use a btrfs bioset instead of abusing bio internals") from
Linus' tree and commit "block: prep work for batch completion" from the
akpm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
I also noticed that a single conversion of bio_endio to bio_endio_batch
is done in the akpm patch but bio_endio_batch is not introduced until a
later patch ... :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/btrfs/inode.c
index af978f7,551c8bd..000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -6932,14 -6928,11 +6932,15 @@@ struct btrfs_dio_private
/* IO errors */
int errors;
+ /* orig_bio is our btrfs_io_bio */
struct bio *orig_bio;
+
+ /* dio_bio came from fs/direct-io.c */
+ struct bio *dio_bio;
};
- static void btrfs_endio_direct_read(struct bio *bio, int err)
+ static void btrfs_endio_direct_read(struct bio *bio, int err,
+ struct batch_complete *batch)
{
struct btrfs_dio_private *dip = bio->bi_private;
struct bio_vec *bvec_end = bio->bi_io_vec + bio->bi_vcnt - 1;
@@@ -6992,12 -6984,12 +6993,13 @@@ failed
/* If we had a csum failure make sure to clear the uptodate flag */
if (err)
- clear_bit(BIO_UPTODATE, &bio->bi_flags);
- dio_end_io(bio, err, batch);
+ clear_bit(BIO_UPTODATE, &dio_bio->bi_flags);
- dio_end_io(dio_bio, err);
++ dio_end_io(dio_bio, err, batch);
+ bio_put(bio);
}
- static void btrfs_endio_direct_write(struct bio *bio, int err)
+ static void btrfs_endio_direct_write(struct bio *bio, int err,
+struct batch_complete *batch)
{
struct btrfs_dio_private *dip = bio->bi_private;
struct inode *inode = dip->inode;
@@@ -7039,9 -7030,8 +7041,9 @@@ out_done
/* If we had an error make sure to clear the uptodate flag */
if (err)
- clear_bit(BIO_UPTODATE, &bio->bi_flags);
- dio_end_io(bio, err, batch);
+ clear_bit(BIO_UPTODATE, &dio_bio->bi_flags);
- dio_end_io(dio_bio, err);
++ dio_end_io(dio_bio, err, batch);
+ bio_put(bio);
}
static int __btrfs_submit_bio_start_direct_io(struct inode *inode, int rw,
diff --cc fs/btrfs/volumes.c
index 8bffb91,7299b55..000
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@@ -5018,9 -5019,35 +5018,10 @@@ int btrfs_rmap_block(struct btrfs_mappi
return 0;
}
- static void btrfs_end_bio(struct bio *bio, int err)
-static void *merge_stripe_index_into_bio_private(void *bi_private,
- unsigned int stripe_index)
-{
- /*
- * with single, dup, RAID0, RAID1 and RAID10, stripe_index is
- * at most 1.
- * The alternative solution (instead of stealing bits from the
- * pointer) would be to allocate an intermediate structure
- * that contains the old private pointer plus the stripe_index.
- */
- BUG_ONuintptr_t)bi_private) & 3) != 0);
- BUG_ON(stripe_index > 3);
- return (void *)(((uintptr_t)bi_private) | stripe_index);
-}
-
-static struct btrfs_bio *extract_bbio_from_bio_private(void *bi_private)
-{
- return (struct btrfs_bio *)(((uintptr_t)bi_private) & ~((uintptr_t)3));
-}
-
-static unsigned int extract_stripe_index_from_bio_private(void *bi_private)
-{
- return (unsigned int)((uintptr_t)bi_private) & 3;
-}
-
+ static void btrfs_end_bio(struct bio *bio, int err,
+ struct batch_complete *batch)
{
- struct btrfs_bio *bbio = extract_bbio_from_bio_private(bio->bi_private);
+ struct btrfs_bio *bbio = bio->bi_private;
int is_orig_bio = 0;
if (err) {
pgpZ9r75T9sP9.pgp
Description: PGP signature
[PATCH] MAINTAINERS: Add myself as maintainer for LM95234 and TMP401 drivers
I wrote the LM95234 driver and extended the TMP401 driver substantially, and I have hardware to test both, so it makes sense to explicitly maintain them. Signed-off-by: Guenter Roeck --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7782b..f0f3d20 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4976,6 +4976,13 @@ S: Maintained F: Documentation/hwmon/lm90 F: drivers/hwmon/lm90.c +LM95234 HARDWARE MONITOR DRIVER +M: Guenter Roeck +L: lm-sens...@lm-sensors.org +S: Maintained +F: Documentation/hwmon/lm95234 +F: drivers/hwmon/lm95234.c + LME2510 MEDIA DRIVER M: Malcolm Priestley L: linux-me...@vger.kernel.org @@ -8182,6 +8189,13 @@ F: drivers/mmc/host/sh_mobile_sdhi.c F: include/linux/mmc/tmio.h F: include/linux/mmc/sh_mobile_sdhi.h +TMP401 HARDWARE MONITOR DRIVER +M: Guenter Roeck +L: lm-sens...@lm-sensors.org +S: Maintained +F: Documentation/hwmon/tmp401 +F: drivers/hwmon/tmp401.c + TMPFS (SHMEM FILESYSTEM) M: Hugh Dickins L: linux...@kvack.org -- 1.7.9.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: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi Braun,
At that time I had an P4080DS board which had the same issue and had been fixed
with this patch.
I didn't test it on P1020 due to the absence of P1020. I think P1020 will need
a new patch besides this one.
Later Ramneek took this issue on P1020 for more investigation.
Hello Ramneek, any update for the PHY_CLK_VALID issue?
Regards,
Shengzhou
> -Original Message-
> From: Michael Braun [mailto:michael.br...@fem.tu-ilmenau.de]
> Sent: Sunday, May 19, 2013 11:23 PM
> To: Liu Shengzhou-B36685
> Cc: projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Alan Stern; linux-kernel@vger.kernel.org
> Subject: Re: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
> Freescale P1020
>
> Hi,
>
> I've got hardware here to test with, so if there any changes to test, I'm
> willing to support.
> Meanwhile, might it be a good idea to make that check optional - i.e. add
> a module parameter or something like this around it?
>
> Regards,
> M. Braun
>
> On Thu, Apr 18, 2013 at 05:13:39PM +0200, michael-dev wrote:
> > Hi,
> >
> > thanks for the quick reply.
> >
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > I applied it, but it does not make any difference on my platform.
> >
> > Regards,
> > M. Braun
> >
> > Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
> > >Hi Braun,
> > >
> > >It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
> > >unstable, introduced by patch "EHCI: centralize controller
> > >initialization".
> > >I submitted a patch to fix it.
> > >Please review the patch http://patchwork.ozlabs.org/patch/237201/
> > >
> > >Regards,
> > >Shengzhou
> > >
> > >
> > >>-Original Message-
> > >>From: Michael Braun [mailto:michael-...@fami-braun.de]
> > >>Sent: Wednesday, April 17, 2013 6:08 PM
> > >>To: Liu Shengzhou-B36685
> > >>Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
> > >>linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> > >>Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
> > >>Freescale P1020
> > >>
> > >>Hi,
> > >>
> > >>I'm running OpenWRT Kernel 3.8.3 (which already has
> > >>f66dea709cd9309b2ee9f715697818001fb518de and
> > >>5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
> > >>(QorlQ,
> > >>PPC) device.
> > >>Before updating the kernel from 3.3.0, USB host support was working
> > >>fine.
> > >>Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and
> > >>the lsusb output is empty, so USB host support is not working. When
> > >>I apply the following patch, USB host support starts working again,
> > >>so I guess
> > >>3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
> > >>Do you have an idea how to fix it more appropriately?
> > >>
> > >>Thanks,
> > >> M. Braun
> > >>
> > >>--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
> > >>+0200
> > >>+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
> > >>+0200
> > >>@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
> > >> if (!spin_event_timeout(in_be32(non_ehci +
> > >>FSL_SOC_USB_CTRL) &
> > >> PHY_CLK_VALID,
> > >>FSL_USB_PHY_CLK_TIMEOUT,
> > >>0)) {
> > >> printk(KERN_WARNING "fsl-ehci: USB PHY
> > >>clock invalid\n");
> > >>- return -EINVAL;
> > >> }
> > >> }
> > >>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/15] f2fs: remove unnecessary flag set
If an inode is recovered with its dentry, it will not invoke __f2fs_add_link,
since the recovery routine checks its dentry before calling __f2fs_add_link.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 2941987..993b601 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -125,11 +125,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
goto next;
entry = get_fsync_inode(head, ino_of_node(page));
- if (entry) {
- if (IS_INODE(page) && is_dent_dnode(page))
- set_inode_flag(F2FS_I(entry->inode),
- FI_INC_LINK);
- } else {
+ if (!entry) {
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] f2fs: remove redundant assignment
We don't need to assign a value redundantly.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 60c8a50..2941987 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -126,7 +126,6 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
entry = get_fsync_inode(head, ino_of_node(page));
if (entry) {
- entry->blkaddr = blkaddr;
if (IS_INODE(page) && is_dent_dnode(page))
set_inode_flag(F2FS_I(entry->inode),
FI_INC_LINK);
@@ -150,10 +149,10 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
kmem_cache_free(fsync_entry_slab, entry);
goto unlock_out;
}
-
list_add_tail(&entry->list, head);
- entry->blkaddr = blkaddr;
}
+ entry->blkaddr = blkaddr;
+
if (IS_INODE(page)) {
err = recover_inode(entry->inode, page);
if (err == -ENOENT) {
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/15] f2fs: remove unnecessary por_doing check
This por_doing check is totally not related to the recovery process. Signed-off-by: Jaegeuk Kim --- fs/f2fs/namei.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 47abc97..729b285 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -149,8 +149,7 @@ static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t mode, alloc_nid_done(sbi, ino); - if (!sbi->por_doing) - d_instantiate(dentry, inode); + d_instantiate(dentry, inode); unlock_new_inode(inode); return 0; out: -- 1.8.1.3.566.gaa39828 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/15] f2fs: fix por_doing variable coverage
The reason of using sbi->por_doing is to alleviate data writes during the recovery. The find_fsync_dnodes() produces some dirty dentry pages, so we should cover it too with sbi->por_doing. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index 993b601..f77aedd 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@ -377,6 +377,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi) INIT_LIST_HEAD(&inode_list); /* step #1: find fsynced inode numbers */ + sbi->por_doing = 1; err = find_fsync_dnodes(sbi, &inode_list); if (err) goto out; @@ -385,13 +386,12 @@ int recover_fsync_data(struct f2fs_sb_info *sbi) goto out; /* step #2: recover data */ - sbi->por_doing = 1; err = recover_data(sbi, &inode_list, CURSEG_WARM_NODE); - sbi->por_doing = 0; BUG_ON(!list_empty(&inode_list)); out: destroy_fsync_dnodes(sbi, &inode_list); kmem_cache_destroy(fsync_entry_slab); + sbi->por_doing = 0; write_checkpoint(sbi, false); return err; } -- 1.8.1.3.566.gaa39828 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/15] f2fs: update inode page after creation
I found a bug when testing power-off-recovery as follows.
[Bug Scenario]
1. create a file
2. fsync the file
3. reboot w/o any sync
4. try to recover the file
- found its fsync mark
- found its dentry mark
: try to recover its dentry
- get its file name
- get its parent inode number
: here we got zero value
The reason why we get the wrong parent inode number is that we didn't
synchronize the inode page with its newly created inode information perfectly.
Especially, previous f2fs stores fi->i_pino and writes it to the cached
node page in a wrong order, which incurs the zero-valued i_pino during the
recovery.
So, this patch modifies the creation flow to fix the synchronization order of
inode page with its inode.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 1 +
fs/f2fs/dir.c | 85 +++---
fs/f2fs/f2fs.h | 3 +--
fs/f2fs/node.c | 12 +++--
4 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index af74549..c320f7f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -279,6 +279,7 @@ repeat:
*
* Also, caller should grab and release a mutex by calling mutex_lock_op() and
* mutex_unlock_op().
+ * Note that, npage is set only by make_empty_dir.
*/
struct page *get_new_data_page(struct inode *inode,
struct page *npage, pgoff_t index, bool new_i_size)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 7db6e58..fc1dacf 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -264,15 +264,10 @@ void f2fs_set_link(struct inode *dir, struct
f2fs_dir_entry *de,
f2fs_put_page(page, 1);
}
-void init_dent_inode(const struct qstr *name, struct page *ipage)
+static void init_dent_inode(const struct qstr *name, struct page *ipage)
{
struct f2fs_node *rn;
- if (IS_ERR(ipage))
- return;
-
- wait_on_page_writeback(ipage);
-
/* copy name info. to this inode page */
rn = (struct f2fs_node *)page_address(ipage);
rn->i.i_namelen = cpu_to_le32(name->len);
@@ -280,14 +275,15 @@ void init_dent_inode(const struct qstr *name, struct page
*ipage)
set_page_dirty(ipage);
}
-static int make_empty_dir(struct inode *inode, struct inode *parent)
+static int make_empty_dir(struct inode *inode,
+ struct inode *parent, struct page *page)
{
struct page *dentry_page;
struct f2fs_dentry_block *dentry_blk;
struct f2fs_dir_entry *de;
void *kaddr;
- dentry_page = get_new_data_page(inode, NULL, 0, true);
+ dentry_page = get_new_data_page(inode, page, 0, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
@@ -317,42 +313,47 @@ static int make_empty_dir(struct inode *inode, struct
inode *parent)
return 0;
}
-static int init_inode_metadata(struct inode *inode,
+static struct page *init_inode_metadata(struct inode *inode,
struct inode *dir, const struct qstr *name)
{
+ struct page *page;
+ int err;
+
if (is_inode_flag_set(F2FS_I(inode), FI_NEW_INODE)) {
- int err;
- err = new_inode_page(inode, name);
- if (err)
- return err;
+ page = new_inode_page(inode, name);
+ if (IS_ERR(page))
+ return page;
if (S_ISDIR(inode->i_mode)) {
- err = make_empty_dir(inode, dir);
- if (err) {
- remove_inode_page(inode);
- return err;
- }
+ err = make_empty_dir(inode, dir, page);
+ if (err)
+ goto error;
}
err = f2fs_init_acl(inode, dir);
- if (err) {
- remove_inode_page(inode);
- return err;
- }
+ if (err)
+ goto error;
+
+ wait_on_page_writeback(page);
} else {
- struct page *ipage;
- ipage = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
- if (IS_ERR(ipage))
- return PTR_ERR(ipage);
- set_cold_node(inode, ipage);
- init_dent_inode(name, ipage);
- f2fs_put_page(ipage, 1);
+ page = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
+ if (IS_ERR(page))
+ return page;
+
+ wait_on_page_writeback(page);
+ set_cold_node(inode, page);
}
- if (is_inode_flag_set(F2FS_I(inode), FI_INC_LINK)) {
+
+ init_dent_inode(name, page);
+
+ if (is_inode_flag_set(F2FS_I(inode), FI_INC_LINK))
inc_nlink(inode);
- update_inode_page(inode);
- }
- return 0;
+ return page;
+
+error:
+ f2fs_p
[PATCH 06/15] f2fs: skip get_node_page if locked node page is passed
If get_dnode_of_data gets a locked node page, let's skip redundant
get_node_page calls.
This is for the futher enhancement.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 9641534..f63f0a4 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -408,10 +408,13 @@ int get_dnode_of_data(struct dnode_of_data *dn, pgoff_t
index, int mode)
level = get_node_path(index, offset, noffset);
nids[0] = dn->inode->i_ino;
- npage[0] = get_node_page(sbi, nids[0]);
- if (IS_ERR(npage[0]))
- return PTR_ERR(npage[0]);
+ npage[0] = dn->inode_page;
+ if (!npage[0]) {
+ npage[0] = get_node_page(sbi, nids[0]);
+ if (IS_ERR(npage[0]))
+ return PTR_ERR(npage[0]);
+ }
parent = npage[0];
if (level != 0)
nids[1] = get_nid(parent, offset[0], true);
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/15] f2fs: fix BUG_ON during f2fs_evict_inode(dir)
During the dentry recovery routine, recover_inode() triggers __f2fs_add_link
with its directory inode.
In the following scenario, a bug is captured.
1. dir = f2fs_iget(pino)
2. __f2fs_add_link(dir, name)
3. iput(dir)
-> f2fs_evict_inode() faces with BUG_ON(atomic_read(fi->dirty_dents))
Kernel BUG at a01c0676 [verbose debug info unavailable]
[] f2fs_evict_inode+0x276/0x300 [f2fs]
Call Trace:
[] evict+0xb0/0x1b0
[] iput+0x105/0x190
[] recover_fsync_data+0x3bc/0x1070 [f2fs]
[] ? io_schedule+0xaa/0xd0
[] ? __wait_on_bit_lock+0x7b/0xc0
[] ? __lock_page+0x67/0x70
[] ? kmem_cache_alloc+0x31/0x140
[] ? __d_instantiate+0x92/0xf0
[] ? security_d_instantiate+0x1b/0x30
[] ? d_instantiate+0x54/0x70
This means that we should flush all the dentry pages between iget and iput().
But, during the recovery routine, it is unallowed due to consistency, so we
have to wait the whole recovery process.
And then, write_checkpoint flushes all the dirty dentry blocks, and nicely we
can put the stale dir inodes from the dirty_dir_inode_list.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 23 +++
fs/f2fs/f2fs.h | 2 ++
fs/f2fs/recovery.c | 14 +-
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index b1de01d..3d11449 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -514,6 +514,29 @@ void remove_dirty_dir_inode(struct inode *inode)
}
out:
spin_unlock(&sbi->dir_inode_lock);
+
+ /* Only from the recovery routine */
+ if (is_inode_flag_set(F2FS_I(inode), FI_DELAY_IPUT))
+ iput(inode);
+}
+
+struct inode *check_dirty_dir_inode(struct f2fs_sb_info *sbi, nid_t ino)
+{
+ struct list_head *head = &sbi->dir_inode_list;
+ struct list_head *this;
+ struct inode *inode = NULL;
+
+ spin_lock(&sbi->dir_inode_lock);
+ list_for_each(this, head) {
+ struct dir_inode_entry *entry;
+ entry = list_entry(this, struct dir_inode_entry, list);
+ if (entry->inode->i_ino == ino) {
+ inode = entry->inode;
+ break;
+ }
+ }
+ spin_unlock(&sbi->dir_inode_lock);
+ return inode;
}
void sync_dirty_dir_inodes(struct f2fs_sb_info *sbi)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 20aab02..ef6cac8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -846,6 +846,7 @@ enum {
FI_INC_LINK,/* need to increment i_nlink */
FI_ACL_MODE,/* indicate acl mode */
FI_NO_ALLOC,/* should not allocate any blocks */
+ FI_DELAY_IPUT, /* used for the recovery */
};
static inline void set_inode_flag(struct f2fs_inode_info *fi, int flag)
@@ -1012,6 +1013,7 @@ int recover_orphan_inodes(struct f2fs_sb_info *);
int get_valid_checkpoint(struct f2fs_sb_info *);
void set_dirty_dir_page(struct inode *, struct page *);
void remove_dirty_dir_inode(struct inode *);
+struct inode *check_dirty_dir_inode(struct f2fs_sb_info *, nid_t);
void sync_dirty_dir_inodes(struct f2fs_sb_info *);
void write_checkpoint(struct f2fs_sb_info *, bool);
void init_orphan_info(struct f2fs_sb_info *);
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index f77aedd..c573944 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -42,6 +42,7 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
{
struct f2fs_node *raw_node = (struct f2fs_node *)kmap(ipage);
struct f2fs_inode *raw_inode = &(raw_node->i);
+ nid_t pino = le32_to_cpu(raw_inode->i_pino);
struct qstr name;
struct f2fs_dir_entry *de;
struct page *page;
@@ -51,10 +52,14 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
if (!is_dent_dnode(ipage))
goto out;
- dir = f2fs_iget(inode->i_sb, le32_to_cpu(raw_inode->i_pino));
- if (IS_ERR(dir)) {
- err = PTR_ERR(dir);
- goto out;
+ dir = check_dirty_dir_inode(F2FS_SB(inode->i_sb), pino);
+ if (!dir) {
+ dir = f2fs_iget(inode->i_sb, pino);
+ if (IS_ERR(dir)) {
+ err = PTR_ERR(dir);
+ goto out;
+ }
+ set_inode_flag(F2FS_I(dir), FI_DELAY_IPUT);
}
name.len = le32_to_cpu(raw_inode->i_namelen);
@@ -67,7 +72,6 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
} else {
err = __f2fs_add_link(dir, &name, inode);
}
- iput(dir);
out:
kunmap(ipage);
return err;
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/15] f2fs: change get_new_data_page to pass a locked node page
This patch is for passing a locked node page to get_dnode_of_data.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 12 +++-
fs/f2fs/dir.c | 4 ++--
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/file.c | 2 +-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 05fb5c6..af74549 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -280,8 +280,8 @@ repeat:
* Also, caller should grab and release a mutex by calling mutex_lock_op() and
* mutex_unlock_op().
*/
-struct page *get_new_data_page(struct inode *inode, pgoff_t index,
- bool new_i_size)
+struct page *get_new_data_page(struct inode *inode,
+ struct page *npage, pgoff_t index, bool new_i_size)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct address_space *mapping = inode->i_mapping;
@@ -289,18 +289,20 @@ struct page *get_new_data_page(struct inode *inode,
pgoff_t index,
struct dnode_of_data dn;
int err;
- set_new_dnode(&dn, inode, NULL, NULL, 0);
+ set_new_dnode(&dn, inode, npage, npage, 0);
err = get_dnode_of_data(&dn, index, ALLOC_NODE);
if (err)
return ERR_PTR(err);
if (dn.data_blkaddr == NULL_ADDR) {
if (reserve_new_block(&dn)) {
- f2fs_put_dnode(&dn);
+ if (!npage)
+ f2fs_put_dnode(&dn);
return ERR_PTR(-ENOSPC);
}
}
- f2fs_put_dnode(&dn);
+ if (!npage)
+ f2fs_put_dnode(&dn);
repeat:
page = grab_cache_page(mapping, index);
if (!page)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 1ac6b93..7db6e58 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -287,7 +287,7 @@ static int make_empty_dir(struct inode *inode, struct inode
*parent)
struct f2fs_dir_entry *de;
void *kaddr;
- dentry_page = get_new_data_page(inode, 0, true);
+ dentry_page = get_new_data_page(inode, NULL, 0, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
@@ -448,7 +448,7 @@ start:
bidx = dir_block_index(level, (le32_to_cpu(dentry_hash) % nbucket));
for (block = bidx; block <= (bidx + nblock - 1); block++) {
- dentry_page = get_new_data_page(dir, block, true);
+ dentry_page = get_new_data_page(dir, NULL, block, true);
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ef6cac8..cbae2b6 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1027,7 +1027,7 @@ int reserve_new_block(struct dnode_of_data *);
void update_extent_cache(block_t, struct dnode_of_data *);
struct page *find_data_page(struct inode *, pgoff_t, bool);
struct page *get_lock_data_page(struct inode *, pgoff_t);
-struct page *get_new_data_page(struct inode *, pgoff_t, bool);
+struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
int f2fs_readpage(struct f2fs_sb_info *, struct page *, block_t, int);
int do_write_data_page(struct page *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 1cae864..b8e34db 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -387,7 +387,7 @@ static void fill_zero(struct inode *inode, pgoff_t index,
f2fs_balance_fs(sbi);
ilock = mutex_lock_op(sbi);
- page = get_new_data_page(inode, index, false);
+ page = get_new_data_page(inode, NULL, index, false);
mutex_unlock_op(sbi, ilock);
if (!IS_ERR(page)) {
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/15] f2fs: add debug msgs in the recovery routine
This patch adds some trivial debugging messages in the recovery process.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 1 -
fs/f2fs/recovery.c | 44 +---
2 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b41482d..5a59780 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1495,7 +1495,6 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct
page *page)
WARN_ON(1);
set_node_addr(sbi, &new_ni, NEW_ADDR);
inc_valid_inode_count(sbi);
-
f2fs_put_page(ipage, 1);
return 0;
}
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index c573944..774efdb 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -49,9 +49,6 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
struct inode *dir;
int err = 0;
- if (!is_dent_dnode(ipage))
- goto out;
-
dir = check_dirty_dir_inode(F2FS_SB(inode->i_sb), pino);
if (!dir) {
dir = f2fs_iget(inode->i_sb, pino);
@@ -73,6 +70,9 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
err = __f2fs_add_link(dir, &name, inode);
}
out:
+ f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode and its dentry: "
+ "ino = %x, name = %s, dir = %lx, err = %d",
+ ino_of_node(ipage), raw_inode->i_name, dir->i_ino, err);
kunmap(ipage);
return err;
}
@@ -83,6 +83,9 @@ static int recover_inode(struct inode *inode, struct page
*node_page)
struct f2fs_node *raw_node = (struct f2fs_node *)kaddr;
struct f2fs_inode *raw_inode = &(raw_node->i);
+ if (!IS_INODE(node_page))
+ return 0;
+
inode->i_mode = le16_to_cpu(raw_inode->i_mode);
i_size_write(inode, le64_to_cpu(raw_inode->i_size));
inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
@@ -92,7 +95,12 @@ static int recover_inode(struct inode *inode, struct page
*node_page)
inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
- return recover_dentry(node_page, inode);
+ if (is_dent_dnode(node_page))
+ return recover_dentry(node_page, inode);
+
+ f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x, name = %s",
+ ino_of_node(node_page), raw_inode->i_name);
+ return 0;
}
static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head)
@@ -123,7 +131,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
lock_page(page);
if (cp_ver != cpver_of_node(page))
- goto unlock_out;
+ break;
if (!is_fsync_dnode(page))
goto next;
@@ -133,40 +141,33 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
struct list_head *head)
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
- goto unlock_out;
+ break;
}
/* add this fsync inode to the list */
entry = kmem_cache_alloc(fsync_entry_slab, GFP_NOFS);
if (!entry) {
err = -ENOMEM;
- goto unlock_out;
+ break;
}
entry->inode = f2fs_iget(sbi->sb, ino_of_node(page));
if (IS_ERR(entry->inode)) {
err = PTR_ERR(entry->inode);
kmem_cache_free(fsync_entry_slab, entry);
- goto unlock_out;
+ break;
}
list_add_tail(&entry->list, head);
}
entry->blkaddr = blkaddr;
- if (IS_INODE(page)) {
- err = recover_inode(entry->inode, page);
- if (err == -ENOENT) {
- goto next;
- } else if (err) {
- err = -EINVAL;
- goto unlock_out;
- }
- }
+ err = recover_inode(entry->inode, page);
+ if (err && err != -ENOENT)
+ break;
next:
/* check next segment */
blkaddr = next_blkaddr_of_node(page);
}
-unlock_out:
unlock_page(page);
out:
__free_pages(page, 0);
@@ -244,7 +245,7 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct
inode *inode,
Re: [PATCH] virtio-net: Reporting traffic queue distribution statistics through ethtool
On 05/20/2013 06:56 AM, Narasimhan, Sriram wrote:
> Hi Michael,
>
> Comments inline...
>
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Sunday, May 19, 2013 1:03 PM
> To: Narasimhan, Sriram
> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jason Wang
> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
> statistics through ethtool
>
> On Sun, May 19, 2013 at 04:09:48PM +, Narasimhan, Sriram wrote:
>> Hi Michael,
>>
>> I was getting all packets on the same inbound queue which
>> is why I added this support to virtio-net (and some more
>> instrumentation at tun as well). But, it turned out to be
>> my misconfiguration - I did not enable IFF_MULTI_QUEUE on
>> the tap device, so the real_num_tx_queues on tap netdev was
>> always 1 (no tx distribution at tap).
> Interesting that qemu didn't fail.
>
> [Sriram] void tun_set_real_num_tx_queues() does not return
> the EINVAL return from netif_set_real_num_tx_queues() for
> txq > dev->num_tx_queues (which would be the case if the
> tap device were not created with IFF_MULTI_QUEUE). I think
> it would be better to fix the code to disable the new
> queue and fail tun_attach() in this scenario. If you
> agree, I can go ahead and create a separate patch for that.
>
But tun_attach() check the TUN_TAP_MQ flags before, so it should fail?
How was the tap created?
>> I am thinking about
>> adding a -q option to tunctl to specify multi-queue flag on
>> the tap device.
> Absolutely.
>
> [Sriram] OK, let me do that.
>
>> Yes, number of exits will be most useful. I will look into
>> adding the other statistics you mention.
>>
>> Sriram
> Pls note you'll need to switch to virtqueue_kick_prepare
> to detect exits: virtqueue_kick doesn't let you know
> whether there was an exit.
>
> Also, it's best to make this a separate patch from the one
> adding per-queue stats.
>
> [Sriram] OK, I will cover only the per-queue statistics in
> this patch. Also, I will address the indentation/data
> structure name points that you mentioned in your earlier
> email and send a new revision for this patch.
>
> Sriram
Better have some performance numbers to make sure nothing was slowed down.
Thanks
>
>> -Original Message-
>> From: Michael S. Tsirkin [mailto:m...@redhat.com]
>> Sent: Sunday, May 19, 2013 4:28 AM
>> To: Narasimhan, Sriram
>> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
>> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
>> statistics through ethtool
>>
>> On Thu, May 16, 2013 at 01:24:29PM -0700, Sriram Narasimhan wrote:
>>> This patch allows virtio-net driver to report traffic distribution
>>> to inbound/outbound queues through ethtool -S. The per_cpu
>>> virtnet_stats is split into receive and transmit stats and are
>>> maintained on a per receive_queue and send_queue basis.
>>> virtnet_stats() is modified to aggregate interface level statistics
>>> from per-queue statistics. Sample output below:
>>>
>> Thanks for the patch. The idea itself looks OK to me.
>> Ben Hutchings already sent some comments
>> so I won't repeat them. Some minor more comments
>> and questions below.
>>
>>> NIC statistics:
>>> rxq0: rx_packets: 4357802
>>> rxq0: rx_bytes: 292642052
>>> txq0: tx_packets: 824540
>>> txq0: tx_bytes: 55256404
>>> rxq1: rx_packets: 0
>>> rxq1: rx_bytes: 0
>>> txq1: tx_packets: 1094268
>>> txq1: tx_bytes: 73328316
>>> rxq2: rx_packets: 0
>>> rxq2: rx_bytes: 0
>>> txq2: tx_packets: 1091466
>>> txq2: tx_bytes: 73140566
>>> rxq3: rx_packets: 0
>>> rxq3: rx_bytes: 0
>>> txq3: tx_packets: 1093043
>>> txq3: tx_bytes: 73246142
>> Interesting. This example implies that all packets are coming in
>> through the same RX queue - is this right?
>> If yes that's worth exploring - could be a tun bug -
>> and shows how this patch is useful.
>>
>>> Signed-off-by: Sriram Narasimhan
>> BTW, while you are looking at the stats, one other interesting
>> thing to add could be checking more types of stats: number of exits,
>> queue full errors, etc.
>>
>>> ---
>>> drivers/net/virtio_net.c | 157
>>> +-
>>> 1 files changed, 128 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 3c23fdc..3c58c52 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -41,15 +41,46 @@ module_param(gso, bool, 0444);
>>>
>>> #define VIRTNET_DRIVER_VERSION "1.0.0"
>>>
>>> -struct virtnet_stats {
>>> - struct u64_stats_sync tx_syncp;
>>> +struct virtnet_rx_stats {
>>> struct u64_stats_sync rx_syncp;
>>> - u64 tx_bytes;
>>> + u64 rx_packets;
>>> + u64 rx_bytes;
>>> +};
>>> +
>>>
RE: [PATCH v3] clocksource: add MVF600 pit timer support
>-Original Message- >From: Shawn Guo [mailto:shawn@linaro.org] >Sent: Monday, May 20, 2013 11:21 AM >To: Lu Jingchang-B35083 >Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >john.stu...@linaro.org; t...@linutronix.de; s.ha...@pengutronix.de >Subject: Re: [PATCH v3] clocksource: add MVF600 pit timer support > >On Mon, May 20, 2013 at 03:08:54AM +, Lu Jingchang-B35083 wrote: >> [Lu Jingchang-B35083] >> I am not sure MVF5xx and MVF7xx have the same PIT block, if you have >information that it is the same on other Vybrid SoCs, it is ok to change >the driver name to mvf. Thanks! > >Even the PIT block on other Vybrid SoCs have differences from the one >integrated on mvf600, we can handle them using device tree compatible >string. And that's why we need to encode SoC name in compatible. > [Lu Jingchang-B35083] Ok, I will rename the driver and the configure option, thanks! >> [Lu Jingchang-B35083] >> PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 >are selected as the clocksource and clockevent device, and leave PIT0 and >PIT1 unused for anyone else who needs them. Thanks! > >This could be an useful info to be in the comment. > [Lu Jingchang-B35083] I will add a comment for this, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Mon, May 20, 2013 at 03:08:54AM +, Lu Jingchang-B35083 wrote: > [Lu Jingchang-B35083] > I am not sure MVF5xx and MVF7xx have the same PIT block, if you have > information that it is the same on other Vybrid SoCs, it is ok to change the > driver name to mvf. Thanks! Even the PIT block on other Vybrid SoCs have differences from the one integrated on mvf600, we can handle them using device tree compatible string. And that's why we need to encode SoC name in compatible. > [Lu Jingchang-B35083] > PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 are > selected as the clocksource and clockevent device, and leave PIT0 and PIT1 > unused for anyone else who needs them. Thanks! This could be an useful info to be in the comment. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs: remove unnecessary kmap/kunmap operations
The allocated page used by the recovery is not on HIGHMEM, so that we don't
need to use kmap/kunmap.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 774efdb..5fcdd08 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -40,11 +40,11 @@ static struct fsync_inode_entry *get_fsync_inode(struct
list_head *head,
static int recover_dentry(struct page *ipage, struct inode *inode)
{
- struct f2fs_node *raw_node = (struct f2fs_node *)kmap(ipage);
+ void *kaddr = page_address(ipage);
+ struct f2fs_node *raw_node = (struct f2fs_node *)kaddr;
struct f2fs_inode *raw_inode = &(raw_node->i);
nid_t pino = le32_to_cpu(raw_inode->i_pino);
struct qstr name;
- struct f2fs_dir_entry *de;
struct page *page;
struct inode *dir;
int err = 0;
@@ -62,8 +62,7 @@ static int recover_dentry(struct page *ipage, struct inode
*inode)
name.len = le32_to_cpu(raw_inode->i_namelen);
name.name = raw_inode->i_name;
- de = f2fs_find_entry(dir, &name, &page);
- if (de) {
+ if (f2fs_find_entry(dir, &name, &page)) {
kunmap(page);
f2fs_put_page(page, 0);
} else {
@@ -73,7 +72,6 @@ out:
f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode and its dentry: "
"ino = %x, name = %s, dir = %lx, err = %d",
ino_of_node(ipage), raw_inode->i_name, dir->i_ino, err);
- kunmap(ipage);
return err;
}
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] f2fs: fix to unlock page before exit
If we got an error after lock_page, we should unlock it before exit.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 5fcdd08..edb89a3 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -343,7 +343,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
lock_page(page);
if (cp_ver != cpver_of_node(page))
- goto unlock_out;
+ break;
entry = get_fsync_inode(head, ino_of_node(page));
if (!entry)
@@ -351,7 +351,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
err = do_recover_data(sbi, entry->inode, page, blkaddr);
if (err)
- goto out;
+ break;
if (entry->blkaddr == blkaddr) {
iput(entry->inode);
@@ -362,7 +362,6 @@ next:
/* check next segment */
blkaddr = next_blkaddr_of_node(page);
}
-unlock_out:
unlock_page(page);
out:
__free_pages(page, 0);
--
1.8.1.3.566.gaa39828
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
Hi, Borislav
On 05/17/2013 09:56 PM, Borislav Petkov wrote:
[snip]
> [ 51.737378] [] native_smp_send_reschedule+0x58/0x60
> [ 51.744013] [] wake_up_nohz_cpu+0x2d/0xa0
I suppose the reason is that the cpu we passed to mod_delayed_work_on()
has a chance to become offline before we disabled irq, what about check
it before send resched ipi? like:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bfa7e77..d0e8f15 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -626,7 +626,7 @@ static bool wake_up_full_nohz_cpu(int cpu)
void wake_up_nohz_cpu(int cpu)
{
- if (!wake_up_full_nohz_cpu(cpu))
+ if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
wake_up_idle_cpu(cpu);
}
Regards,
Michael Wang
> [ 51.749745] [] add_timer_on+0x8f/0x110
> [ 51.755214] [] __queue_delayed_work+0x16e/0x1a0
> [ 51.761470] [] ? try_to_grab_pending+0xd1/0x1a0
> [ 51.767724] [] mod_delayed_work_on+0x5a/0xa0
> [ 51.773719] [] gov_queue_work+0x4d/0xc0
> [ 51.779271] [] od_dbs_timer+0xcb/0x170
> [ 51.784734] [] process_one_work+0x1fd/0x540
> [ 51.790634] [] ? process_one_work+0x192/0x540
> [ 51.796711] [] worker_thread+0x122/0x380
> [ 51.802350] [] ? rescuer_thread+0x320/0x320
> [ 51.808264] [] kthread+0xea/0xf0
> [ 51.813200] [] ? flush_kthread_worker+0x150/0x150
> [ 51.819644] [] ret_from_fork+0x7c/0xb0
> [ 51.918165] nouveau E[ DRM] GPU lockup - switching to software fbcon
> [ 51.930505] [] ? flush_kthread_worker+0x150/0x150
> [ 51.936994] ---[ end trace f419538ada83b5c5 ]---
> [ 51.942915] [ cut here ]
> [ 51.942928] [ cut here ]
> [ 51.942936] WARNING: at arch/x86/kernel/smp.c:123
> native_smp_send_reschedule+0x58/0x60()
> [ 51.942974] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi
> usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel
> snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm
> aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer
> xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich
> acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common
> soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
> [ 51.942978] CPU: 5 PID: 740 Comm: kworker/3:2 Tainted: GW
> 3.10.0-rc1+ #10
> [ 51.942979] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
> 01/24/2013
> [ 51.942985] Workqueue: events od_dbs_timer
> [ 51.942990] 0009 88043ab0db68 8161441c
> 88043ab0dba8
> [ 51.942994] 8103e540 3ab0dbf8 0003
> 88043d708000
> [ 51.942998] 0d32 0003 88044fccfc08
> 88043ab0dbb8
> [ 51.942999] Call Trace:
> [ 51.943005] [] dump_stack+0x19/0x1b
> [ 51.943010] [] warn_slowpath_common+0x70/0xa0
> [ 51.943014] [] warn_slowpath_null+0x1a/0x20
> [ 51.943017] [] native_smp_send_reschedule+0x58/0x60
> [ 51.943021] [] wake_up_nohz_cpu+0x2d/0xa0
> [ 51.943027] [] add_timer_on+0x8f/0x110
> [ 51.943031] [] __queue_delayed_work+0x16e/0x1a0
> [ 51.943035] [] ? try_to_grab_pending+0xd1/0x1a0
> [ 51.943038] [] mod_delayed_work_on+0x5a/0xa0
> [ 51.943043] [] gov_queue_work+0x4d/0xc0
> [ 51.943046] [] od_dbs_timer+0xcb/0x170
> [ 51.943050] [] process_one_work+0x1fd/0x540
> [ 51.943053] [] ? process_one_work+0x192/0x540
> [ 51.943057] [] worker_thread+0x122/0x380
> [ 51.943060] [] ? rescuer_thread+0x320/0x320
> [ 51.943063] [] kthread+0xea/0xf0
> [ 51.943068] [] ? flush_kthread_worker+0x150/0x150
> [ 51.943071] [] ret_from_fork+0x7c/0xb0
> [ 51.943074] [] ? flush_kthread_worker+0x150/0x150
> [ 51.943076] ---[ end trace f419538ada83b5c6 ]---
> [ 52.178461] WARNING: at arch/x86/kernel/smp.c:123
> native_smp_send_reschedule+0x58/0x60()
> [ 52.188097] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi
> usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel
> snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm
> aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer
> xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich
> acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common
> soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
> [ 52.238477] CPU: 0 PID: 85 Comm: kworker/2:1 Tainted: GW
> 3.10.0-rc1+ #10
> [ 52.247669] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08
> 01/24/2013
> [ 52.256604] Workqueue: events od_dbs_timer
> [ 52.262219] 0009 88043b62db68 8161441c
> 88043b62dba8
> [ 52.271194] 8103e540 0033 0002
> 88043d6dc000
> [ 52.280163] 0d32 0002 88044fc8fc08
> 88043b62dbb8
> [ 52.289141] Call Trace:
> [ 52.293066]
RE: [PATCH v3] clocksource: add MVF600 pit timer support
>-Original Message- >From: Shawn Guo [mailto:shawn@linaro.org] >Sent: Monday, May 20, 2013 10:28 AM >To: Lu Jingchang-B35083 >Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >john.stu...@linaro.org; t...@linutronix.de; s.ha...@pengutronix.de >Subject: Re: [PATCH v3] clocksource: add MVF600 pit timer support > >On Thu, May 16, 2013 at 02:15:24PM +0800, Jingchang Lu wrote: >> Add Freescale Vybrid MVF600 period interrupt timer support. >> >> Signed-off-by: Jingchang Lu >> --- >> v3: >> move the pit driver to drivers/clocksource. >> >> drivers/clocksource/Kconfig| 5 + >> drivers/clocksource/Makefile | 1 + >> drivers/clocksource/mvf600_pit_timer.c | 224 >> + > >This is a driver for PIT, a timer IP block found on mvf family. Even >though we prefer to use particular SoC name to specify the compatibility >and version of the block, all the versions of the IP block should be >ideally supported by single PIT driver. This is just like we have drivers >spi-imx and i2c-imx support all SPI and I2C controllers found on IMX SoCs. >That said, I suggest you use family name "mvf" to name the driver, Kconfig >symbol etc. and use "mvf600" only in compatible string. > [Lu Jingchang-B35083] I am not sure MVF5xx and MVF7xx have the same PIT block, if you have information that it is the same on other Vybrid SoCs, it is ok to change the driver name to mvf. Thanks! >> 3 files changed, 230 insertions(+) >> + >> +/* choose PIT2 as clocksource, PIT3 as clockevent dev */ > >Reading the comment, I have a natural question - what PIT0 and PIT1 are >used for? > [Lu Jingchang-B35083] PIT0 and PIT1 can be chained to build a 64-bit timer, so PIT2 and PIT3 are selected as the clocksource and clockevent device, and leave PIT0 and PIT1 unused for anyone else who needs them. Thanks! > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the rr-fixes tree
Stephen Rothwell writes:
> Hi Rusty,
>
> After merging the rr-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/dma/iovlock.c: In function 'dma_pin_iovec_pages':
> drivers/dma/iovlock.c:98:21: error: dereferencing pointer to incomplete type
>down_read(¤t->mm->mmap_sem);
> ^
> drivers/dma/iovlock.c:101:11: error: dereferencing pointer to incomplete type
> current->mm,
>^
> drivers/dma/iovlock.c:108:19: error: dereferencing pointer to incomplete type
>up_read(¤t->mm->mmap_sem);
>^
>
> Caused by commit 11227d242a8c ("Hoist memcpy_fromiovec/memcpy_toiovec
> into lib/"). Clearly, net/tcp.h was indirectly including sched.h or
> asm/current.h. Changing inclusions is fraught with problems since people
> do not follow Rule 1 (in Documentation/SubmitChecklist) consistently. :-(
Yep, the 0day tester caught this too (it works on 32-bit unfortunately,
so I didn't see the problem).
I've not touched the #includes any more in my updated patch.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation
With the recent patches added to kernel crypto for improving AES support, adding aesni etc, it seems like it is time to add AES CMAC to the cifs kernel module (for the popular SMB3 signing and per-share encryption) but needed for an implementation for SP800-138 in kernel crypto codebase. Was specifically interested using the way defined in 3.1.4.2 of MS-SMB2 document, in particular KDF in Counter mode (section 5.1 of NIST SP 800-108) or a way to specify a mode PRF as HMAC-SHA256 (or a way to specify a PRF) cifs client would use this algorithm for SMB3.0 MAC generation (network packet signing on network file system mounts to newer generation NAS, and Windows 2012) and also for per-share encryption (which is also available on the most recent generation of NAS via SMB3). Apparently with current Intel processors having hardware for this kind of encryption offload - full packet encryption is faster than packet signing used to be (with the older standard algorithms) and just doing packet signing is really fast. Are their APIs in crypto kernel code to use for this purpose? Regards, Shirish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/20/2013 10:20 AM, Greg Kroah-Hartman wrote: > On Mon, May 20, 2013 at 10:12:41AM +0800, Chen Gang wrote: >> > I mean that if no reply by any other members within a week, I will know >> > it is correct that "we need not call device_remove_file() firstly before >> > call device_unregister()" (at least, one member's reply supports this >> > conclusion). >> > >> > I find this 'question' when discussing a patch with another members in >> > linux-kernel@vger.kernel.org, I have read the related code and also have >> > searched with google, but can not find the result, so I want to consult >> > it in linux-kernel@vger.kernel.org. > Asking random questions on lkml, and relying on the fact that no one > else happens to say anything, is not any judge as to if the answer is > correct at all. > OK, I can understand, now, thank you for your reply. And I wish, we can provide the confirmation of all related questions about Linux kernel, in the future, > In fact, just asking questions on lkml has a very low chance of ever > getting a correct answer, given that the people that usually do know the > answer to these types of things are usually: > 1) not reading lkml because they are busy doing real work I should understand, they have no duty to have to reply the related mail, especially every members already have their own work (and normally, they are really busy). > 2) annoyed by questions that are easily answered by themselves by > either: >a) reading the code I have done, so I need not worry about this item. :-) >b) writing a simple example module and testing it out yourself > Precisely, I did not do it firstly. It seems I should do it firstly (although, at least now, I do not think it will get any valuable result for our this case) > > Good luck, > OK, 'Lucky' is really the first important !! I should continue to analyze this question, independent this 'consult' mail. Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] virtio_pci: better macro exported in uapi
"Michael S. Tsirkin" writes: > Macro VIRTIO_PCI_CONFIG assumes that userspace actually has a structure > with a field named msix_enabled. Add VIRTIO_PCI_CONFIG_OFF that gets > the msix_enabled by value instead, to make it useful for userspace. We > still keep VIRTIO_PCI_CONFIG around for now, in case some userspace uses > it. > > Signed-off-by: Michael S. Tsirkin Applied. Thanks, Rusty. > --- > > Changes from v1: > - rename macro to VIRTIO_PCI_CONFIG_OFF so preprocessor > can be used to check for its presence, as suggested > by Rusty > - keep old macro around as suggested by David Howells > > include/uapi/linux/virtio_pci.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h > index ea66f3f..e5ec1ca 100644 > --- a/include/uapi/linux/virtio_pci.h > +++ b/include/uapi/linux/virtio_pci.h > @@ -80,7 +80,9 @@ > > /* The remaining space is defined by each driver as the per-driver > * configuration space */ > -#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20) > +#define VIRTIO_PCI_CONFIG_OFF(msix_enabled) ((msix_enabled) ? 24 : 20) > +/* Deprecated: please use VIRTIO_PCI_CONFIG_OFF instead */ > +#define VIRTIO_PCI_CONFIG(dev) > VIRTIO_PCI_CONFIG_OFF((dev)->msix_enabled) > > /* Virtio ABI version, this must match exactly */ > #define VIRTIO_PCI_ABI_VERSION 0 > -- > MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio_pci: fix macro exported in uapi
David Howells writes: > Rusty Russell wrote: > >> Macro still isn't usable, because userspace can't know whether it's the >> new or old. >> >> We need to either remove it from UAPI, or rename it to >> VIRTIO_PCI_CONFIG_OFF. > > Surely, if userspace is using it as is, you can't remove it, rename it or > alter it? The point of the patch is that it's unusable: #define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20) ie. it's accessing a member of the kernel's virtio_pci_dev structure. In theory, userspace could have a structure with the same field and be using it now, but that's unlikely (qemu certainly doesn't). No harm no foul. In theory it's actually a useful macro, so we could expose it to userspace, but we'd need to have a new name so userspace can #ifdef for older headers... Hope that clarifies, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v7 0/21] sched: power aware scheduling
Hi Alex, On 05/20/2013 06:31 AM, Alex Shi wrote: > >> Which are the workloads where 'powersaving' mode hurts workload >> performance measurably? >> >> I ran ebizzy on a 2 socket, 16 core, SMT 4 Power machine. > > Is this a 2 * 16 * 4 LCPUs PowerPC machine? This is a 2 * 8 * 4 LCPUs PowerPC machine. >> The power efficiency drops significantly with the powersaving policy of >> this patch,over the power efficiency of the scheduler without this patch. >> >> The below parameters are measured relative to the default scheduler >> behaviour. >> >> A: Drop in power efficiency with the patch+powersaving policy >> B: Drop in performance with the patch+powersaving policy >> C: Decrease in power consumption with the patch+powersaving policy >> >> NumThreads AB C >> - >> 2 33% 36% 4% >> 4 31% 33% 3% >> 8 28% 30% 3% >> 16 31% 33% 4% >> >> Each of the above run is for 30s. >> >> On investigating socket utilization,I found that only 1 socket was being >> used during all the above threaded runs. As can be guessed this is due >> to the group_weight being considered for the threshold metric. >> This stacks up tasks on a core and further on a socket, thus throttling >> them, as observed by Mike below. >> >> I therefore think we must switch to group_capacity as the metric for >> threshold and use only (rq->utils*nr_running) for group_utils >> calculation during non-bursty wakeup scenarios. >> This way we are comparing right; the utilization of the runqueue by the >> fair tasks and the cpu capacity available for them after being consumed >> by the rt tasks. >> >> After I made the above modification,all the above three parameters came >> to be nearly null. However, I am observing the load balancing of the >> scheduler with the patch and powersavings policy enabled. It is behaving >> very close to the default scheduler (spreading tasks across sockets). >> That also explains why there is no performance drop or gain with the >> patch+powersavings policy enabled. I will look into this observation and >> revert. > > Thanks a lot for the great testings! > Seem tasks per SMT cpu isn't power efficient. > And I got the similar result last week. I tested the fspin testing(do > endless calculation, in linux-next tree.). when I bind task per SMT cpu, > the power efficiency really dropped with most every threads number. but > when bind task per core, it has better power efficiency on all threads. > Beside to move task depend on group_capacity, another choice is balance > task according cpu_power. I did the transfer in code. but need to go > through a internal open source process before public them. What do you mean by *another* choice is balance task according to cpu_power? group_capacity is based on cpu_power. Also, your balance policy in v6 was doing the same right? It was rightly comparing rq->utils * nr_running against cpu_power. Why not simply switch to that code for power policy load balancing? > Well, it'll lose throughput any time there's parallel execution > potential but it's serialized instead.. using average will inevitably > stack tasks sometimes, but that's its goal. Hackbench shows it. (but that consolidation can be a winner too, and I bet a nickle it would be for a socket sized pgbench run) >>> >>> (belay that, was thinking of keeping all tasks on a single node, but >>> it'll likely stack the whole thing on a CPU or two, if so, it'll hurt) >> >> At this point, I would like to raise one issue. >> *Is the goal of the power aware scheduler improving power efficiency of >> the scheduler or a compromise on the power efficiency but definitely a >> decrease in power consumption, since it is the user who has decided to >> prioritise lower power consumption over performance* ? >> > > It could be one of reason for this feather, but I could like to > make it has better efficiency, like packing tasks according to cpu_power > not current group_weight. Yes we could try the patch using group_capacity and observe the results for power efficiency, before we decide to compromise on power efficiency for decrease in power. Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] x86: asus-laptop: fix invalid point access
asus->name is null or point to const string,so it is not suitable to kfree it. Signed-off-by: Libo Chen --- drivers/platform/x86/asus-laptop.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c index 0eea09c..8e268da 100644 --- a/drivers/platform/x86/asus-laptop.c +++ b/drivers/platform/x86/asus-laptop.c @@ -1935,7 +1935,6 @@ fail_input: fail_backlight: asus_platform_exit(asus); fail_platform: - kfree(asus->name); kfree(asus); return result; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86 platform drivers: fix gpio leak
when request_irq faild, we should release gpiochip
Signed-off-by: Libo Chen
---
drivers/platform/x86/intel_pmic_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
mode change 100644 => 100755 drivers/platform/x86/intel_pmic_gpio.c
diff --git a/drivers/platform/x86/intel_pmic_gpio.c
b/drivers/platform/x86/intel_pmic_gpio.c
old mode 100644
new mode 100755
index 6f4b728..478c3a5
--- a/drivers/platform/x86/intel_pmic_gpio.c
+++ b/drivers/platform/x86/intel_pmic_gpio.c
@@ -288,7 +288,7 @@ static int platform_pmic_gpio_probe(struct platform_device
*pdev)
retval = request_irq(pg->irq, pmic_irq_handler, 0, "pmic", pg);
if (retval) {
pr_warn("Interrupt request failed\n");
- goto err;
+ goto fail_request_irq;
}
for (i = 0; i < 8; i++) {
@@ -299,6 +299,9 @@ static int platform_pmic_gpio_probe(struct platform_device
*pdev)
irq_set_chip_data(i + pg->irq_base, pg);
}
return 0;
+
+fail_request_irq:
+ gpiochip_remove(&pg->chip);
err:
iounmap(pg->gpiointr);
err2:
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] fix x86 driver memleak
fix memleak or invalite point acesss about x86 platform drivers Libo Chen (3): x86: msi-laptop: fix memleak x86: asus-laptop: fix invalid point access x86 platform drivers: fix gpio leak drivers/platform/x86/asus-laptop.c | 1 - drivers/platform/x86/intel_pmic_gpio.c | 5 - drivers/platform/x86/msi-laptop.c | 24 ++-- 3 files changed, 14 insertions(+), 16 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86: msi-laptop: fix memleak
1. fix two visible mistakes:
* when load_scm_model_init faild, we should call
platform_device_del(msipf_device)
* msipf_attribute_group should be remove in err case
2. change some tags, give them real meaning.
Signed-off-by: Libo Chen
---
drivers/platform/x86/msi-laptop.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
mode change 100644 => 100755 drivers/platform/x86/msi-laptop.c
diff --git a/drivers/platform/x86/msi-laptop.c
b/drivers/platform/x86/msi-laptop.c
old mode 100644
new mode 100755
index 6b22938..62f8030
--- a/drivers/platform/x86/msi-laptop.c
+++ b/drivers/platform/x86/msi-laptop.c
@@ -1098,29 +1098,29 @@ static int __init msi_init(void)
ret = platform_device_add(msipf_device);
if (ret)
- goto fail_platform_device1;
+ goto fail_device_add;
if (quirks->load_scm_model && (load_scm_model_init(msipf_device) < 0)) {
ret = -EINVAL;
- goto fail_platform_device1;
+ goto fail_scm_model_init;
}
ret = sysfs_create_group(&msipf_device->dev.kobj,
&msipf_attribute_group);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_group;
if (!quirks->old_ec_model) {
if (threeg_exists)
ret = device_create_file(&msipf_device->dev,
&dev_attr_threeg);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_attr;
} else {
ret = sysfs_create_group(&msipf_device->dev.kobj,
&msipf_old_attribute_group);
if (ret)
- goto fail_platform_device2;
+ goto fail_create_attr;
/* Disable automatic brightness control by default because
* this module was probably loaded to do brightness control in
@@ -1134,26 +1134,22 @@ static int __init msi_init(void)
return 0;
-fail_platform_device2:
-
+fail_create_attr:
+ sysfs_remove_group(&msipf_device->dev.kobj, &msipf_attribute_group);
+fail_create_group:
if (quirks->load_scm_model) {
i8042_remove_filter(msi_laptop_i8042_filter);
cancel_delayed_work_sync(&msi_rfkill_dwork);
cancel_work_sync(&msi_rfkill_work);
rfkill_cleanup();
}
+fail_scm_model_init:
platform_device_del(msipf_device);
-
-fail_platform_device1:
-
+fail_device_add:
platform_device_put(msipf_device);
-
fail_platform_driver:
-
platform_driver_unregister(&msipf_driver);
-
fail_backlight:
-
backlight_device_unregister(msibl_device);
return ret;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] clocksource: add MVF600 pit timer support
On Thu, May 16, 2013 at 02:15:24PM +0800, Jingchang Lu wrote:
> Add Freescale Vybrid MVF600 period interrupt timer support.
>
> Signed-off-by: Jingchang Lu
> ---
> v3:
> move the pit driver to drivers/clocksource.
>
> drivers/clocksource/Kconfig| 5 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/mvf600_pit_timer.c | 224
> +
This is a driver for PIT, a timer IP block found on mvf family. Even
though we prefer to use particular SoC name to specify the compatibility
and version of the block, all the versions of the IP block should be
ideally supported by single PIT driver. This is just like we have
drivers spi-imx and i2c-imx support all SPI and I2C controllers found on
IMX SoCs.
That said, I suggest you use family name "mvf" to name the driver,
Kconfig symbol etc. and use "mvf600" only in compatible string.
> 3 files changed, 230 insertions(+)
> create mode 100644 drivers/clocksource/mvf600_pit_timer.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index f151c6c..2808a76 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -85,3 +85,8 @@ config CLKSRC_SAMSUNG_PWM
> Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
> for all devicetree enabled platforms. This driver will be
> needed only on systems that do not have the Exynos MCT available.
> +
> +config MVF600_PIT_TIMER
> + bool
> + help
> + Support for Period Interrupt Timer on Freescale Vybrid MVF600 SoC.
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 8d979c7..f471ca3 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_BCM) += bcm_kona_timer.o
> obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
> obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
> obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> +obj-$(CONFIG_MVF600_PIT_TIMER) += mvf600_pit_timer.o
>
> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
> obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
> diff --git a/drivers/clocksource/mvf600_pit_timer.c
> b/drivers/clocksource/mvf600_pit_timer.c
> new file mode 100644
> index 000..74f7963
> --- /dev/null
> +++ b/drivers/clocksource/mvf600_pit_timer.c
> @@ -0,0 +1,224 @@
> +/*
> + * Copyright 2012-2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * 8 timers: pit0 - pit7,
> + * Each takes 0x10 Bytes register sapce
s/sapce/space
> + */
> +#define PITMCR 0x00
> +#define PIT0_OFFSET 0x100
> +#define PITn_OFFSET(n) (PIT0_OFFSET + 0x10 * (n))
> +#define PITLDVAL 0x00
> +#define PITCVAL 0x04
> +#define PITTCTRL 0x08
> +#define PITTFLG 0x0c
> +
> +#define PITTCTRL_TEN (0x1 << 0)
> +#define PITTCTRL_TIE (0x1 << 1)
> +#define PITCTRL_CHN (0x1 << 2)
Use space than tab between "#define" and macro name.
> +
> +#define PITTFLG_TIF 0x1
> +
> +static struct clock_event_device clockevent_pit;
> +static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;
> +
> +static void __iomem *clksrc_base;
> +static void __iomem *clkevt_base;
> +static void __iomem *sched_clock_reg;
> +static unsigned long pit_cycle_per_jiffy;
> +
> +static inline void pit_timer_enable(void)
> +{
> + __raw_writel(PITTCTRL_TEN | PITTCTRL_TIE, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_timer_disable(void)
> +{
> + __raw_writel(0, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_disable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val &= ~PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static inline void pit_irq_enable(void)
> +{
> + unsigned long val;
> +
> + val = __raw_readl(clkevt_base + PITTCTRL);
> + val |= PITTCTRL_TIE;
> + __raw_writel(val, clkevt_base + PITTCTRL);
> +}
> +
> +static void pit_irq_acknowledge(void)
> +{
> + __raw_writel(PITTFLG_TIF, clkevt_base + PITTFLG);
> +}
> +
> +static unsigned int pit_read_sched_clock(void)
> +{
> + return __raw_readl(sched_clock_reg);
> +}
> +
> +
> +static int __init pit_clocksource_init(struct clk *pit_clk)
> +{
> + unsigned int c = clk_get_rate(pit_clk);
> +
> + sched_clock_reg = clksrc_base + PITCVAL;
> +
> + setup_sched_clock(pit_read_sched_clock, 32, c);
> + return clocksource_mmio_init(clksrc_base + PITCVAL, "mvf600-pit", c,
> + 300, 32, clo
[PATCH v6 05/10 fix] mtd: get the ECC info from the Extended Parameter Page
Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
to store the ECC info.
The onfi spec tells us that if the nand chip's recommended ECC codeword
size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
read the Extended ECC information that is part of the extended parameter
page to retrieve the ECC requirements for this device.
This patch implement the reading of the Extended Parameter Page, and parses
the sections for ECC type, and get the ECC info from the ECC section.
Tested this patch with Micron MT29F64G08CBABAWP.
Acked-by: Pekon Gupta
Signed-off-by: Huang Shijie
---
drivers/mtd/nand/nand_base.c | 88 ++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index b63b731..3edf825 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2835,6 +2835,79 @@ static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
return crc;
}
+/* Parse the Extended Parameter Page. */
+static int nand_flash_detect_ext_param_page(struct mtd_info *mtd,
+ struct nand_chip *chip, struct nand_onfi_params *p)
+{
+ struct onfi_ext_param_page *ep;
+ struct onfi_ext_section *s;
+ struct onfi_ext_ecc_info *ecc;
+ uint8_t *cursor;
+ int ret = -EINVAL;
+ int len;
+ int i;
+
+ len = le16_to_cpu(p->ext_param_page_length) * 16;
+ ep = kmalloc(len, GFP_KERNEL);
+ if (!ep) {
+ ret = -ENOMEM;
+ goto ext_out;
+ }
+
+ /* Send our own NAND_CMD_PARAM. */
+ chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+
+ /* Use the Change Read Column command to skip the ONFI param pages. */
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
+ sizeof(*p) * p->num_of_param_pages , -1);
+
+ /* Read out the Extended Parameter Page. */
+ chip->read_buf(mtd, (uint8_t *)ep, len);
+ if ((onfi_crc16(ONFI_CRC_BASE, ((uint8_t *)ep) + 2, len - 2)
+ != le16_to_cpu(ep->crc))) {
+ pr_debug("fail in the CRC.\n");
+ goto ext_out;
+ }
+
+ /*
+* From section 5.7.2.2, we know that the Extened Param Page is valid
+* when two or more bytes of the signatrue are valid.
+* So we only check the first two bytes here.
+*/
+ if (strncmp(ep->sig, "EP", 2)) {
+ pr_debug("The signatrue is invalid.\n");
+ goto ext_out;
+ }
+
+ /* find the ECC section. */
+ cursor = (uint8_t *)(ep + 1);
+ for (i = 0; i < ONFI_EXT_SECTION_MAX; i++) {
+ s = ep->sections + i;
+ if (s->type == ONFI_SECTION_TYPE_2)
+ break;
+ cursor += s->length * 16;
+ }
+ if (i == ONFI_EXT_SECTION_MAX) {
+ pr_debug("We can not find the ECC section.\n");
+ goto ext_out;
+ }
+
+ /* get the info we want. */
+ ecc = (struct onfi_ext_ecc_info *)cursor;
+
+ if (ecc->codeword_size) {
+ chip->ecc_strength_ds = ecc->ecc_bits;
+ chip->ecc_step_ds = 1 << ecc->codeword_size;
+ }
+
+ pr_info("ONFI extended param page detected.\n");
+ return 0;
+
+ext_out:
+ kfree(ep);
+ return ret;
+}
+
/*
* Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
*/
@@ -2903,6 +2976,21 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd,
struct nand_chip *chip,
if (p->ecc_bits != 0xff) {
chip->ecc_strength_ds = p->ecc_bits;
chip->ecc_step_ds = 512;
+ } else if (chip->onfi_version >= 21 &&
+ (onfi_feature(chip) & ONFI_FEATURE_EXT_PARAM_PAGE)) {
+
+ /*
+* The nand_flash_detect_ext_param_page() uses the
+* Change Read Column command which maybe not supported
+* by the chip->cmdfunc. So try to update the chip->cmdfunc
+* now. We do not replace user supplied command function.
+*/
+ if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
+ chip->cmdfunc = nand_command_lp;
+
+ /* The Extended Parameter Page is supported since ONFI 2.1. */
+ if (nand_flash_detect_ext_param_page(mtd, chip, p))
+ pr_info("Failed to detect the extended param page.\n");
}
pr_info("ONFI flash detected\n");
--
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: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On Mon, May 20, 2013 at 10:12:41AM +0800, Chen Gang wrote: > I mean that if no reply by any other members within a week, I will know > it is correct that "we need not call device_remove_file() firstly before > call device_unregister()" (at least, one member's reply supports this > conclusion). > > I find this 'question' when discussing a patch with another members in > linux-kernel@vger.kernel.org, I have read the related code and also have > searched with google, but can not find the result, so I want to consult > it in linux-kernel@vger.kernel.org. Asking random questions on lkml, and relying on the fact that no one else happens to say anything, is not any judge as to if the answer is correct at all. In fact, just asking questions on lkml has a very low chance of ever getting a correct answer, given that the people that usually do know the answer to these types of things are usually: 1) not reading lkml because they are busy doing real work 2) annoyed by questions that are easily answered by themselves by either: a) reading the code b) writing a simple example module and testing it out yourself Good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/20/2013 09:45 AM, Greg Kroah-Hartman wrote: > On Mon, May 20, 2013 at 09:03:27AM +0800, Chen Gang wrote: >> > On 05/18/2013 07:06 PM, Ming Lei wrote: >>> > > Hi, >>> > > >>> > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang >>> > > wrote: > >> Hello All: > >> > >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are > >> 'obey > >> this rule', even in device_unregister() itself, it also firstly calls > >> device_remove_file(), then call kobject_del(). > >> > >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it > >> seems kobject_del() -> sysfs_remove_dir() which will release all > >> related > >> things (can instead of device_remove_file()). > >> > >> So in fact, we need not call device_remove_file() before call > >> device_unregister(), is it correct ? >>> > > >>> > > Looks it is correct but it is a bit implicit. >>> > > >> > >> > If really no other members reply within a week, we should treat your >> > opinion (or suggestion) as the final result conclusion within >> > linux-kernel@vger.kernel.org. :-) > I have no idea what you mean by this. > I mean that if no reply by any other members within a week, I will know it is correct that "we need not call device_remove_file() firstly before call device_unregister()" (at least, one member's reply supports this conclusion). I find this 'question' when discussing a patch with another members in linux-kernel@vger.kernel.org, I have read the related code and also have searched with google, but can not find the result, so I want to consult it in linux-kernel@vger.kernel.org. And I think, this 'question' is not suitable to give a test firstly, because the test plan need be discussed firstly (or the test result means nothing). This time, I send the 'consult' mail to 'All', not to specific members. Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vhost-scsi: Depend on NET for memcpy_fromiovec
On Fri, May 17, 2013 at 04:25:49PM +0930, Rusty Russell wrote:
> Randy Dunlap writes:
> > On 05/16/13 16:42, Rusty Russell wrote:
> >> Joe Perches writes:
> >>> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
> Asias He writes:
> > On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
> >>> []
> > Other users are using memcpy_fromiovec and friends outside net. It seems
> > a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
> > which also depends on NET for it.
> >>>
> >>> []
> Subject: Hoist memcpy_fromiovec into lib/
> >>>
> >>> You'll need the "friends" memcpy_toiovec too.
> >>>
> >>> $ git grep -E \bmemcpy\w+iovec\w*"
> >>> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result,
> >>> len);
> >>> crypto/algif_skcipher.c:err =
> >>> memcpy_fromiovec(page_address(sg_page(sg)) +
> >>> crypto/algif_skcipher.c:err =
> >>> memcpy_fromiovec(page_address(sg_page(sg + i)),
> >>> drivers/dma/iovlock.c:#include /* for memcpy_toiovec */
> >>> drivers/dma/iovlock.c: return memcpy_toiovec(iov, kdata, len);
> >>> drivers/dma/iovlock.c: err = memcpy_toiovec(iov, vaddr + offset,
> >>> len);
> >>> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len),
> >>> msg->msg_iov, len)) {
> >>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
> >>> memcpy_fromiovec((u8 *)va + page_o
> >>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
> >>> memcpy_toiovec(iov, (u8 *)va + pag
> >>
> >> Fascinating. These all indirectly depend on NET, so there's no problem
> >> at the moment. But it is a bit weird...
> >>
> >> crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
> >> crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
> >> drivers/dma/iovlock.c: depends on NET_DMA -> NET
> >> drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
> >> drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET
> >>
> >> Patch welcome.
> >>
> >> Meanwhile, to avoid more bikeshedding I've put the patch I posted with
> >> all acks in my fixes branch. One cycle through linux-next, then
> >> straight to Linus.
> >>
> >
> > I agree with whoever suggested that more be moved into /lib.
> > E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the
> > code there uses both memcpy_toiovec() and memcpy_fromiovec().
> > See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.
>
> (CC's trimmed).
>
> You Acked that commit :(
>
> At a glance, the only way to drive the vmw_vmci device is through
> net/vmw_vsock/vmci_transport.c, so without NET it's useless? But let's
> keep it neat anyway. This was compiletested with CONFIG_VMCI,
> CONFIG_DMA_ENGINE and !CONFIG_NET.
>
> Thanks,
> Rusty.
>
> From: Rusty Russell
> Subject: [PATCH] Hoist memcpy_fromiovec/memcpy_toiovec into lib/
>
> ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
>
> That function is only present with CONFIG_NET. Turns out that
> crypto/algif_skcipher.c also uses that outside net, but it actually
> needs sockets anyway.
>
> In addition, commit 6d4f0139d642c45411a47879325891ce2a7c164a added
> CONFIG_NET dependency to CONFIG_VMCI for memcpy_toiovec, so hoist
> that function and revert that commit too.
>
> socket.h already include uio.h, so no callers *need* updating,
> though I update the obvious ones.
>
> Reported-by: Randy Dunlap
> Acked-by: David S. Miller
> Acked-by: Michael S. Tsirkin
> Signed-off-by: Rusty Russell
Acked-by: Asias He
> diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
> index bb48a57..6943deb66 100644
> --- a/drivers/dma/iovlock.c
> +++ b/drivers/dma/iovlock.c
> @@ -28,7 +28,7 @@
> #include
> #include
> #include
> -#include /* for memcpy_toiovec */
> +#include /* for memcpy_toiovec */
> #include
> #include
>
> diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
> index ea98f7e..39c2eca 100644
> --- a/drivers/misc/vmw_vmci/Kconfig
> +++ b/drivers/misc/vmw_vmci/Kconfig
> @@ -4,7 +4,7 @@
>
> config VMWARE_VMCI
> tristate "VMware VMCI Driver"
> - depends on X86 && PCI && NET
> + depends on X86 && PCI
> help
> This is VMware's Virtual Machine Communication Interface. It enables
> high-speed communication between host and guest in a virtual
> diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> index d94245d..8ff2e5e 100644
> --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> @@ -23,7 +23,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 428c37a..33bf2df 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -305,7 +305,6 @@ struct ucred {
>
> extern void cred_to_ucred(
RE: [PATCH 3.9-stable] NTB: variable dereferenced before check
Jon Mason agrees that this could also be applied to the 3.9
"Yes, please do. I'll respond to each of the patch series, but please apply
them all. Also, one patch was omitted from these, titled
NTB: variable dereferenced before check
Please include that patch in 3.9 stable as well.
"
Thanks.
Best Regards.
> -Original Message-
> From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org]
> On Behalf Of Jonghwan Choi
> Sent: Monday, May 20, 2013 10:58 AM
> To: 'Jonghwan Choi'; linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org; 'Jon Mason'; c...@samsung.com
> Subject: [PATCH 3.9-stable] NTB: variable dereferenced before check
>
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?
>
> --
>
> From: "Jon Mason "
>
> commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
>
> Correct instances of variable dereferencing before checking its value on
> the functions exported to the client drivers. Also, add sanity checks
> for all exported functions.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Jon Mason
> Signed-off-by: Jonghwan Choi
> ---
> drivers/ntb/ntb_transport.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index e0bdfd7..74c5812 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
> */
> void ntb_transport_free_queue(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> struct ntb_queue_entry *entry;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> +
> cancel_delayed_work_sync(&qp->link_work);
>
> ntb_unregister_db_callback(qp->ndev, qp->qp_num);
> @@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
> */
> void ntb_transport_link_down(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> int rc, val;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> qp->client_ready = NTB_LINK_DOWN;
>
> rc = ntb_read_local_spad(qp->ndev, QP_LINKS, &val);
> @@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
> */
> bool ntb_transport_link_query(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return false;
> +
> return qp->qp_link == NTB_LINK_UP;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> @@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> */
> unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->qp_num;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> @@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> */
> unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->tx_max_frame - sizeof(struct ntb_payload_header);
> }
> EXPORT_SYMBOL_GPL(ntb_transport_max_size);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: variable dereferenced before check
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
Correct instances of variable dereferencing before checking its value on
the functions exported to the client drivers. Also, add sanity checks
for all exported functions.
Reported-by: Dan Carpenter
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index e0bdfd7..74c5812 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
*/
void ntb_transport_free_queue(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
struct ntb_queue_entry *entry;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
+
cancel_delayed_work_sync(&qp->link_work);
ntb_unregister_db_callback(qp->ndev, qp->qp_num);
@@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
*/
void ntb_transport_link_down(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
int rc, val;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
qp->client_ready = NTB_LINK_DOWN;
rc = ntb_read_local_spad(qp->ndev, QP_LINKS, &val);
@@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
*/
bool ntb_transport_link_query(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return false;
+
return qp->qp_link == NTB_LINK_UP;
}
EXPORT_SYMBOL_GPL(ntb_transport_link_query);
@@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
*/
unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->qp_num;
}
EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
@@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
*/
unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->tx_max_frame - sizeof(struct ntb_payload_header);
}
EXPORT_SYMBOL_GPL(ntb_transport_max_size);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On Mon, May 20, 2013 at 09:03:27AM +0800, Chen Gang wrote: > On 05/18/2013 07:06 PM, Ming Lei wrote: > > Hi, > > > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang wrote: > >> Hello All: > >> > >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are 'obey > >> this rule', even in device_unregister() itself, it also firstly calls > >> device_remove_file(), then call kobject_del(). > >> > >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it > >> seems kobject_del() -> sysfs_remove_dir() which will release all related > >> things (can instead of device_remove_file()). > >> > >> So in fact, we need not call device_remove_file() before call > >> device_unregister(), is it correct ? > > > > Looks it is correct but it is a bit implicit. > > > > If really no other members reply within a week, we should treat your > opinion (or suggestion) as the final result conclusion within > linux-kernel@vger.kernel.org. :-) I have no idea what you mean by this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cdrom: gdrom: fix device number leak
"repost with Jens Axboe added" suggest by Tejun Heo
without this patch, gdrom_major will leak when gd.cd_info alloc faild
Signed-off-by: Libo Chen
---
drivers/cdrom/gdrom.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 4afcb65..5980cb9 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -830,9 +830,9 @@ probe_fail_cdrom_register:
del_gendisk(gd.disk);
probe_fail_no_disk:
kfree(gd.cd_info);
+probe_fail_no_mem:
unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
gdrom_major = 0;
-probe_fail_no_mem:
pr_warning("Probe failed - error is 0x%X\n", err);
return err;
}
--
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] pwm: renesas-tpu: Add missing pwmchip_remove() call in tpu_remove()
On Sun, May 19, 2013 at 04:22:21PM +0200, Laurent Pinchart wrote:
> Hi Axel,
>
> Thank you for the patch.
>
> On Sunday 19 May 2013 13:45:31 Axel Lin wrote:
> > Signed-off-by: Axel Lin
> > ---
> > drivers/pwm/pwm-renesas-tpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-renesas-tpu.c b/drivers/pwm/pwm-renesas-tpu.c
> > index 8e6d8d7..351addd 100644
> > --- a/drivers/pwm/pwm-renesas-tpu.c
> > +++ b/drivers/pwm/pwm-renesas-tpu.c
> > @@ -444,7 +444,7 @@ static int tpu_remove(struct platform_device *pdev)
> >
> > pm_runtime_disable(&pdev->dev);
> >
> > - return 0;
> > + return pwmchip_remove(&tpu->chip);
>
> Could you please move that line at the beginning of the function ? There
> would
> be a race condition otherwise, as the user could reenable PWM between the
> tpu_pwm_timer_stop() calls and the pwmchip_remove() call.
>
> Apart from that, the patch looks good.
Also, could you please CC linux...@vger.kernel.org,
that will help me track the change through patchwork.
Thanks!
>
> > }
> >
> > static struct platform_driver tpu_driver = {
>
> --
> Regards,
>
> Laurent Pinchart
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91: Fix: Change internal SRAM memory type to "MT_MEMORY_SO"
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index e2f4bdd..d68be6c 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -80,7 +80,7 @@ void __init at91_init_sram(int bank, unsigned long base,
unsigned int length)
desc->pfn = __phys_to_pfn(base);
desc->length = length;
- desc->type = MT_DEVICE;
+ desc->type = MT_MEMORY_SO;
pr_info("AT91: sram at 0x%lx of 0x%x mapped at 0x%lx\n",
base, length, desc->virtual);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Change internal SRAM memory type to "MT_MEMORY_SO"
Hi Russell, This patch is to change the internal SRAM memory type to "MT_MEMORY_SO", the right type. It tested on sama5d3xek boards. It based on v3.10-rc1. Best Regards, Wenyou Yang Wenyou Yang (1): ARM: at91: Fix: Change internal SRAM memory type to "MT_MEMORY_SO" arch/arm/mach-at91/setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
On 05/18/2013 07:06 PM, Ming Lei wrote: > Hi, > > On Fri, May 17, 2013 at 1:43 PM, Chen Gang wrote: >> Hello All: >> >> I searched 'arch/*' and 'drivers/*' sub-directory, all of them are 'obey >> this rule', even in device_unregister() itself, it also firstly calls >> device_remove_file(), then call kobject_del(). >> >> But after read the related code (fs/sysfs/*, drivers/base/core.c), it >> seems kobject_del() -> sysfs_remove_dir() which will release all related >> things (can instead of device_remove_file()). >> >> So in fact, we need not call device_remove_file() before call >> device_unregister(), is it correct ? > > Looks it is correct but it is a bit implicit. > If really no other members reply within a week, we should treat your opinion (or suggestion) as the final result conclusion within linux-kernel@vger.kernel.org. :-) Thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 0/21] sched: power aware scheduling
> Which are the workloads where 'powersaving' mode hurts workload > performance measurably? > > I ran ebizzy on a 2 socket, 16 core, SMT 4 Power machine. Is this a 2 * 16 * 4 LCPUs PowerPC machine? > The power efficiency drops significantly with the powersaving policy of > this patch,over the power efficiency of the scheduler without this patch. > > The below parameters are measured relative to the default scheduler > behaviour. > > A: Drop in power efficiency with the patch+powersaving policy > B: Drop in performance with the patch+powersaving policy > C: Decrease in power consumption with the patch+powersaving policy > > NumThreads AB C > - > 2 33% 36% 4% > 4 31% 33% 3% > 8 28% 30% 3% > 16 31% 33% 4% > > Each of the above run is for 30s. > > On investigating socket utilization,I found that only 1 socket was being > used during all the above threaded runs. As can be guessed this is due > to the group_weight being considered for the threshold metric. > This stacks up tasks on a core and further on a socket, thus throttling > them, as observed by Mike below. > > I therefore think we must switch to group_capacity as the metric for > threshold and use only (rq->utils*nr_running) for group_utils > calculation during non-bursty wakeup scenarios. > This way we are comparing right; the utilization of the runqueue by the > fair tasks and the cpu capacity available for them after being consumed > by the rt tasks. > > After I made the above modification,all the above three parameters came > to be nearly null. However, I am observing the load balancing of the > scheduler with the patch and powersavings policy enabled. It is behaving > very close to the default scheduler (spreading tasks across sockets). > That also explains why there is no performance drop or gain with the > patch+powersavings policy enabled. I will look into this observation and > revert. Thanks a lot for the great testings! Seem tasks per SMT cpu isn't power efficient. And I got the similar result last week. I tested the fspin testing(do endless calculation, in linux-next tree.). when I bind task per SMT cpu, the power efficiency really dropped with most every threads number. but when bind task per core, it has better power efficiency on all threads. Beside to move task depend on group_capacity, another choice is balance task according cpu_power. I did the transfer in code. but need to go through a internal open source process before public them. > Well, it'll lose throughput any time there's parallel execution potential but it's serialized instead.. using average will inevitably stack tasks sometimes, but that's its goal. Hackbench shows it. >>> >>> (but that consolidation can be a winner too, and I bet a nickle it would >>> be for a socket sized pgbench run) >> >> (belay that, was thinking of keeping all tasks on a single node, but >> it'll likely stack the whole thing on a CPU or two, if so, it'll hurt) > > At this point, I would like to raise one issue. > *Is the goal of the power aware scheduler improving power efficiency of > the scheduler or a compromise on the power efficiency but definitely a > decrease in power consumption, since it is the user who has decided to > prioritise lower power consumption over performance* ? > It could be one of reason for this feather, but I could like to make it has better efficiency, like packing tasks according to cpu_power not current group_weight. >> > > Regards > Preeti U Murthy > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the rr-fixes tree
Hi Rusty,
After merging the rr-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/dma/iovlock.c: In function 'dma_pin_iovec_pages':
drivers/dma/iovlock.c:98:21: error: dereferencing pointer to incomplete type
down_read(¤t->mm->mmap_sem);
^
drivers/dma/iovlock.c:101:11: error: dereferencing pointer to incomplete type
current->mm,
^
drivers/dma/iovlock.c:108:19: error: dereferencing pointer to incomplete type
up_read(¤t->mm->mmap_sem);
^
Caused by commit 11227d242a8c ("Hoist memcpy_fromiovec/memcpy_toiovec
into lib/"). Clearly, net/tcp.h was indirectly including sched.h or
asm/current.h. Changing inclusions is fraught with problems since people
do not follow Rule 1 (in Documentation/SubmitChecklist) consistently. :-(
I have used the rr-fixes tree from next-20130515 (since the fix in
rr-fixes in next-20130516/7 conflicts with the better fix now in Linus'
tree) for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp76Rgl5YvYG.pgp
Description: PGP signature
Re: [PATCH] leds: leds-gpio: reserve gpio before using it
Friday, May 17, 2013 4:49 PM, Timo Teras wrote: > > This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) > and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() > flags param correctly) which was a fix of the first one. > > The conversion to devm_gpio_request in commit e3b1d44c (leds: > leds-gpio: use devm_gpio_request_one) is not reverted. > > The problem is that gpio_cansleep() and gpio_get_value_cansleep() > calls can crash if the gpio is not first reserved. Incidentally this > same bug existed earlier and was fixed similarly in commit d95cbe61 > (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens > when GPIOs are provided by module which is not yet loaded. > > So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): > > BUG: unable to handle kernel NULL pointer dereference at 004c > IP: [] __gpio_cansleep+0xe/0x1a > *pde = > Oops: [#1] SMP > Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core > geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat > ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd > ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop > Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine > EIP: 0060:[] EFLAGS: 00010282 CPU: 0 > EIP is at __gpio_cansleep+0xe/0x1a > EAX: EBX: cf364018 ECX: c132b8b9 EDX: > ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > CR0: 8005003b CR2: 004c CR3: 0f0c4000 CR4: 0090 > DR0: DR1: DR2: DR3: > DR6: 0ff0 DR7: 0400 > Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) > Stack: > cded9de0 d09471cb c1399260 cf364014 c1399260 c1399254 > d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 > c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 > Call Trace: > [] gpio_led_probe+0xba/0x203 [leds_gpio] > [] platform_drv_probe+0x26/0x48 > [] driver_probe_device+0x75/0x15c > [] __driver_attach+0x47/0x63 > [] bus_for_each_dev+0x3c/0x66 > [] driver_attach+0x14/0x16 > [] ? driver_probe_device+0x15c/0x15c > [] bus_add_driver+0xbd/0x1bc > [] ? 0xd08b3fff > [] ? 0xd08b3fff > [] driver_register+0x74/0xec > [] ? 0xd08b3fff > [] platform_driver_register+0x38/0x3a > [] gpio_led_driver_init+0xd/0x1000 [leds_gpio] > [] do_one_initcall+0x6b/0x10f > [] ? 0xd08b3fff > [] load_module+0x1631/0x1907 > [] ? insert_vmalloc_vmlist+0x14/0x43 > [] ? __vmalloc_node_range+0x13e/0x15f > [] sys_init_module+0x62/0x77 > [] syscall_call+0x7/0xb > EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc > CR2: 004c > ---[ end trace 5308fb20d2514822 ]--- > > Signed-off-by: Timo Ter?s > Cc: Jingoo Han Acked-by: Jingoo Han I look at what happens in leds-gpio. As you mentioned, devm_gpio_request() should be called before gpio_cansleep() and gpio_get_value_cansleep are called. Thank you for sending the patch. Best regards, Jingoo Han > Cc: Sachin Kamat > Cc: Raphael Assenat > Cc: Trent Piepho > Cc: Javier Martinez Canillas > Cc: Arnaud Patard > Cc: Ezequiel Garcia > --- > drivers/leds/leds-gpio.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c > index a0d931b..b02b679 100644 > --- a/drivers/leds/leds-gpio.c > +++ b/drivers/leds/leds-gpio.c > @@ -107,6 +107,10 @@ static int create_gpio_led(const struct gpio_led > *template, > return 0; > } > > + ret = devm_gpio_request(parent, template->gpio, template->name); > + if (ret < 0) > + return ret; > + > led_dat->cdev.name = template->name; > led_dat->cdev.default_trigger = template->default_trigger; > led_dat->gpio = template->gpio; > @@ -126,10 +130,7 @@ static int create_gpio_led(const struct gpio_led > *template, > if (!template->retain_state_suspended) > led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME; > > - ret = devm_gpio_request_one(parent, template->gpio, > - (led_dat->active_low ^ state) ? > - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, > - template->name); > + ret = gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state); > if (ret < 0) > return ret; > > -- > 1.8.2.3 >
linux-next: manual merge of the usb.current tree with Linus' tree
Hi Greg,
Today's linux-next merge of the usb.current tree got a conflict in
drivers/usb/host/ohci-nxp.c between commit bb522812a1a6
("drivers/usb/host: don't check resource with devm_ioremap_resource")
from Linus' tree and commit b3517d5de80e ("usb: ohci: fix goto wrong tag
in err case") from the usb.current tree.
The former remove a bit of code modified by the latter, so I did that and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpccBrxkSni6.pgp
Description: PGP signature
[PATCH testing] mrf24j40: Move INIT_COMPLETION to before the packet is sent
This avoids a race condition where the tx_complete interrupt could happen before the completion is initialized. --- David H, Try this out and see if it changes anything for you. I put a bunch of schedule_timeout()s in mrf24j40_tx() to basically guarantee that a reception will happen during mrf24j40_tx(), and it seems to work. It would not work before with said schedule_timeout() calls. Alan. --- drivers/net/ieee802154/mrf24j40.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c index 556151d..0ea2a5a 100644 --- a/drivers/net/ieee802154/mrf24j40.c +++ b/drivers/net/ieee802154/mrf24j40.c @@ -345,6 +345,8 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb) if (ret) goto err; + INIT_COMPLETION(devrec->tx_complete); + /* Set TXNTRIG bit of TXNCON to send packet */ ret = read_short_reg(devrec, REG_TXNCON, &val); if (ret) @@ -355,8 +357,6 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb) val |= 0x4; write_short_reg(devrec, REG_TXNCON, val); - INIT_COMPLETION(devrec->tx_complete); - /* Wait for the device to send the TX complete interrupt. */ ret = wait_for_completion_interruptible_timeout( &devrec->tx_complete, -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: question about the pwm tree
Hi Thierry, I noticed that you changed the email address for the maintainer of the pwm tree in the MAINTAINERS file. should I use this new address as your contact for linux-next as well? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpI7a6E0qm98.pgp Description: PGP signature
Re: [PATCHv11 3/4] zswap: add to mm/
On Fri, May 17, 2013 at 05:54:18PM +0100, Mel Gorman wrote: > On Mon, May 13, 2013 at 07:40:02AM -0500, Seth Jennings wrote: > > zswap is a thin compression backend for frontswap. It receives pages from > > frontswap and attempts to store them in a compressed memory pool, resulting > > in > > an effective partial memory reclaim and dramatically reduced swap device > > I/O. > > > > potentially reduces IO. No guarantees. Sorry, I was in marketing mode I guess. > > Additionally, in most cases, pages can be retrieved from this compressed > > store > > much more quickly than reading from tradition swap devices resulting in > > faster > > performance for many workloads. > > > > While this is likely, it's also not necessarily true if the swap device > is particularly fast. Also, swap devices can be asynchronously written, > is the same true for zswap? I doubt it as I would expect the compression > operation to slow down pages being added to swap cache. Same here. The compression happens synchronously at pageout() time, more precisely the frontswap_store() in swap_writepage(). The advantage here is that pages synchronously stored in zswap can be immediately reclaimed in shrink_page_list(). > > > It also has support for evicting swap pages that are currently compressed in > > zswap to the swap device on an LRU(ish) basis. > > I know I initially suggested an LRU but don't worry about this thing > being an LRU too much. A FIFO list would be just fine as the pages are > presumably idle if they ended up in zswap in the first place. The LRU stuff is already in zbud and doesn't add much complexity. It is cheap and understandable so may as well do it I figure. You'll have to select a page one way or another. May as well be consistent with the rest of the MM. > > +/* > > +* statistics > > +**/ > > +/* Number of memory pages used by the compressed pool */ > > +static atomic_t zswap_pool_pages = ATOMIC_INIT(0); > > They underlying allocator should be tracking the number of physical > pages used, not this layer. zbud does track the number of pool pages. This variable just mirrors the zbud value when it has the potential to change so that it is accessible in the zswap debugfs. However, since the conversion to zbud, this atomic isn't inc/dec anymore, just set, so no need to be atomic. > > > +/* The number of compressed pages currently stored in zswap */ > > +static atomic_t zswap_stored_pages = ATOMIC_INIT(0); > > + > > +/* > > + * The statistics below are not protected from concurrent access for > > + * performance reasons so they may not be a 100% accurate. However, > > + * they do provide useful information on roughly how many times a > > + * certain event is occurring. > > +*/ > > +static u64 zswap_pool_limit_hit; > > +static u64 zswap_written_back_pages; > > +static u64 zswap_reject_reclaim_fail; > > +static u64 zswap_reject_compress_poor; > > +static u64 zswap_reject_alloc_fail; > > +static u64 zswap_reject_kmemcache_fail; > > +static u64 zswap_duplicate_entry; > > + > > Document what these mean. Will do. > > > +/* > > +* tunables > > +**/ > > +/* Enable/disable zswap (disabled by default, fixed at boot for now) */ > > +static bool zswap_enabled; > > read_mostly Yep. > > > +module_param_named(enabled, zswap_enabled, bool, 0); > > + > > +/* Compressor to be used by zswap (fixed at boot for now) */ > > +#define ZSWAP_COMPRESSOR_DEFAULT "lzo" > > +static char *zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT; > > +module_param_named(compressor, zswap_compressor, charp, 0); > > + > > +/* The maximum percentage of memory that the compressed pool can occupy */ > > +static unsigned int zswap_max_pool_percent = 20; > > +module_param_named(max_pool_percent, > > + zswap_max_pool_percent, uint, 0644); > > + > > This will need additional love in the future. If you have an 8 node machine > then zswap pool could completely exhaust a single NUMA node with this > parameter. This is pretty much a big fat hammer that stops zswap getting > compltely out of control and taking over the system but it'll need some > sort of sensible automatic resizing based on system activity in the future. > It's not an obstacle to merging because you have to start somewhere but > the fixed-pool size thing is fugly and you should plan on putting it down > in the future. Agreed, it is a starting point and making this policy better and NUMA-aware is at the top of my TODO list. > > > +/* > > + * Maximum compression ratio, as as percentage, for an acceptable > > + * compressed page. Any pages that do not compress by at least > > + * this ratio will be rejected. > > +*/ > > +static unsigned int zswap_max_compression_ratio = 80; > > +module_param_named(max_compression_ratio, > > + zswap_max_compression_ratio, uint, 0644); > > + > > I would be very surprised if a user w
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
Randy Dunlap writes:
> On 05/16/13 16:42, Rusty Russell wrote:
>> Joe Perches writes:
>>> On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
Asias He writes:
> On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
>>> []
> Other users are using memcpy_fromiovec and friends outside net. It seems
> a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
> which also depends on NET for it.
>>>
>>> []
Subject: Hoist memcpy_fromiovec into lib/
>>>
>>> You'll need the "friends" memcpy_toiovec too.
>>>
>>> $ git grep -E \bmemcpy\w+iovec\w*"
>>> crypto/algif_hash.c:err = memcpy_toiovec(msg->msg_iov, ctx->result,
>>> len);
>>> crypto/algif_skcipher.c:err =
>>> memcpy_fromiovec(page_address(sg_page(sg)) +
>>> crypto/algif_skcipher.c:err =
>>> memcpy_fromiovec(page_address(sg_page(sg + i)),
>>> drivers/dma/iovlock.c:#include /* for memcpy_toiovec */
>>> drivers/dma/iovlock.c: return memcpy_toiovec(iov, kdata, len);
>>> drivers/dma/iovlock.c: err = memcpy_toiovec(iov, vaddr + offset,
>>> len);
>>> drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len),
>>> msg->msg_iov, len)) {
>>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
>>> memcpy_fromiovec((u8 *)va + page_o
>>> drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
>>> memcpy_toiovec(iov, (u8 *)va + pag
>>
>> Fascinating. These all indirectly depend on NET, so there's no problem
>> at the moment. But it is a bit weird...
>>
>> crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH -> NET
>> crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER -> NET
>> drivers/dma/iovlock.c: depends on NET_DMA -> NET
>> drivers/isdn/mISDN/socket.c: depends on MISDN -> ISDN -> NET
>> drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI -> NET
>>
>> Patch welcome.
>>
>> Meanwhile, to avoid more bikeshedding I've put the patch I posted with
>> all acks in my fixes branch. One cycle through linux-next, then
>> straight to Linus.
>>
>
> I agree with whoever suggested that more be moved into /lib.
> E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the
> code there uses both memcpy_toiovec() and memcpy_fromiovec().
> See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.
(CC's trimmed).
You Acked that commit :(
At a glance, the only way to drive the vmw_vmci device is through
net/vmw_vsock/vmci_transport.c, so without NET it's useless? But let's
keep it neat anyway. This was compiletested with CONFIG_VMCI,
CONFIG_DMA_ENGINE and !CONFIG_NET.
Thanks,
Rusty.
From: Rusty Russell
Subject: [PATCH] Hoist memcpy_fromiovec/memcpy_toiovec into lib/
ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
That function is only present with CONFIG_NET. Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.
In addition, commit 6d4f0139d642c45411a47879325891ce2a7c164a added
CONFIG_NET dependency to CONFIG_VMCI for memcpy_toiovec, so hoist
that function and revert that commit too.
socket.h already include uio.h, so no callers *need* updating,
though I update the obvious ones.
Reported-by: Randy Dunlap
Acked-by: David S. Miller
Acked-by: Michael S. Tsirkin
Signed-off-by: Rusty Russell
diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
index bb48a57..6943deb66 100644
--- a/drivers/dma/iovlock.c
+++ b/drivers/dma/iovlock.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include /* for memcpy_toiovec */
+#include /* for memcpy_toiovec */
#include
#include
diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
index ea98f7e..39c2eca 100644
--- a/drivers/misc/vmw_vmci/Kconfig
+++ b/drivers/misc/vmw_vmci/Kconfig
@@ -4,7 +4,7 @@
config VMWARE_VMCI
tristate "VMware VMCI Driver"
- depends on X86 && PCI && NET
+ depends on X86 && PCI
help
This is VMware's Virtual Machine Communication Interface. It enables
high-speed communication between host and guest in a virtual
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index d94245d..8ff2e5e 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 428c37a..33bf2df 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -305,7 +305,6 @@ struct ucred {
extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct
ucred *ucred);
-extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len);
extern int csum_partial_copy_fromiovecend(unsigned char *kda
pipe/fifo, set exception for select() when read end is not open
I've been looking at the gule hacks I have to use to get inotifywait to work in shell scripts. So I figgered I would hack inotifywait to look at exceptions in its select() loop. No joy. inotifywait loops using select() to look for changes to at least one inotify FD. Whenever it sees a change, it reads the event and sends it to stdout. Cool. This works well and uses little CPU time. But there's a problem. Suppose you have inotifywait monitoring a specific file for a change, such as "wait for this file to be deleted." And you have piped inotifywait to "while read a b c". The problem is that when the 'while' loop gets the DELETE event, it does what is needed and exits. And it is expected that inotifywait will exit. But because the file it was watching has been deleted and can cause no more events, inotifywait will never receive another event, never return from select(), never write to the pipe, and never know that the pipe's reader exitted. It will never know that it should exit. Then I got to wondering why it is that writing to a pipe is the *only* way to know that the reader end is or has been closed (other than via complicated signalling). And wondering why. Would it be possible to set an exception on a pipe's or fifo's writer FD when the reader FD is not open (when there are no readers or when there are none left)? Would it be reasonable to do this? I imagine a pipe should have a 'last reader closed' exception, while fifos could benefit from that and/or a 'no readers' exception. If this exception existed, inotifywait could watch for read and exception changes using select(). An exception on stdout would almost certainly mean that the pipe has been welded shut, so inotifywait should just exit. This can't be the only example of a program that could benefit from knowing that one of its output pipes is closed without needing to write to the pipe to find out. Thanks, N (Please CC me on replies.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 2/2] mrf24j40: Keep the interrupt line enabled
On 05/16/2013 05:34 PM, David Hauweele wrote:
> I have seen the interrupt line going low forever with heavy traffic.
Hi David,
I've been doing some testing today and I can reproduce your issue if I
ping -f both ways simultaneously (after about 3-4 minutes usually). I
think it has more to do with the tx/rx mutual exclusion that you
described in patch 1/1 than it does with the disable/enable IRQ. With
respect to enable/disable irq, I did some checking of other similar
drivers (non-ieee802154) and noticed that many of them use threaded
interrupts. I think this may be closer to the right way to do it.
Are you running a tickless kernel? What is your preemption model? What's
your hardware platform?
> The at86rf230 driver has two isr, one for edge-triggered and another
> for level-triggered interrupt. The latter uses
> disable_irq_nosync/enable_irq which makes sense for level-triggered
> interrupt. Otherwise the interrupt would be triggered again and again
> until the scheduled work read the status register.
>
> However I don't see the use of disable_irq/enable_irq with an
> edge-triggered interrupt. Perhaps I'm missing something. Though I
> don't see any harm using it anyway.
My understanding based on the datasheet is that the interrupt can be
asserted again as soon as INTSTAT is read (which is done in the
workqueue). I guess even if it happens while the workqueue is running,
it's ok.
I think I had a flawed understanding of schedule_work() before, thinking
that it would not schedule a work_struct it if the work_struct was running.
> As you said the interrupt should
> be delayed until enable_irq() is called. In particular when
> CONFIG_HARDIRQS_SW_RESEND is set.
I think I agree with you. I'll send you a patch to try with threaded
interrupts to try.
I'm trying to determine exactly what's the cause of the interrupt line
being stuck low.
Alan.
>
> 2013/5/14 Alan Ott :
>> On 5/9/13 11:19 AM, David Hauweele wrote:
>>> Disabling the interrupt line could miss an IRQ and leave the line into a
>>> low state hence locking the driver.
>>>
>> Have you observed this? My understanding is that the interrupt won't be lost
>> but instead delayed until enable_irq() is called.
>>
>> I got this pattern from the other 802.15.4 drivers. Perhaps my understanding
>> is wrong.
>>
>>
>>
>>> Signed-off-by: David Hauweele
>>> ---
>>> drivers/net/ieee802154/mrf24j40.c |7 +--
>>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ieee802154/mrf24j40.c
>>> b/drivers/net/ieee802154/mrf24j40.c
>>> index 1e3ddf3..6ef32f7 100644
>>> --- a/drivers/net/ieee802154/mrf24j40.c
>>> +++ b/drivers/net/ieee802154/mrf24j40.c
>>> @@ -603,8 +603,6 @@ static irqreturn_t mrf24j40_isr(int irq, void *data)
>>> {
>>> struct mrf24j40 *devrec = data;
>>>
>>> - disable_irq_nosync(irq);
>>> -
>>> schedule_work(&devrec->irqwork);
>>>
>>> return IRQ_HANDLED;
>>> @@ -619,7 +617,7 @@ static void mrf24j40_isrwork(struct work_struct *work)
>>> /* Read the interrupt status */
>>> ret = read_short_reg(devrec, REG_INTSTAT, &intstat);
>>> if (ret)
>>> - goto out;
>>> + return;
>>>
>>> /* Check for TX complete */
>>> if (intstat & 0x1)
>>> @@ -628,9 +626,6 @@ static void mrf24j40_isrwork(struct work_struct *work)
>>> /* Check for Rx */
>>> if (intstat & 0x8)
>>> schedule_work(&devrec->rxwork);
>>> -
>>> -out:
>>> - enable_irq(devrec->spi->irq);
>>> }
>>>
>>> static void mrf24j40_rxwork(struct work_struct *work)
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] virtio-net: Reporting traffic queue distribution statistics through ethtool
Hi Michael,
Comments inline...
-Original Message-
From: Michael S. Tsirkin [mailto:m...@redhat.com]
Sent: Sunday, May 19, 2013 1:03 PM
To: Narasimhan, Sriram
Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
Jason Wang
Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
statistics through ethtool
On Sun, May 19, 2013 at 04:09:48PM +, Narasimhan, Sriram wrote:
> Hi Michael,
>
> I was getting all packets on the same inbound queue which
> is why I added this support to virtio-net (and some more
> instrumentation at tun as well). But, it turned out to be
> my misconfiguration - I did not enable IFF_MULTI_QUEUE on
> the tap device, so the real_num_tx_queues on tap netdev was
> always 1 (no tx distribution at tap).
Interesting that qemu didn't fail.
[Sriram] void tun_set_real_num_tx_queues() does not return
the EINVAL return from netif_set_real_num_tx_queues() for
txq > dev->num_tx_queues (which would be the case if the
tap device were not created with IFF_MULTI_QUEUE). I think
it would be better to fix the code to disable the new
queue and fail tun_attach() in this scenario. If you
agree, I can go ahead and create a separate patch for that.
> I am thinking about
> adding a -q option to tunctl to specify multi-queue flag on
> the tap device.
Absolutely.
[Sriram] OK, let me do that.
> Yes, number of exits will be most useful. I will look into
> adding the other statistics you mention.
>
> Sriram
Pls note you'll need to switch to virtqueue_kick_prepare
to detect exits: virtqueue_kick doesn't let you know
whether there was an exit.
Also, it's best to make this a separate patch from the one
adding per-queue stats.
[Sriram] OK, I will cover only the per-queue statistics in
this patch. Also, I will address the indentation/data
structure name points that you mentioned in your earlier
email and send a new revision for this patch.
Sriram
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Sunday, May 19, 2013 4:28 AM
> To: Narasimhan, Sriram
> Cc: ru...@rustcorp.com.au; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] virtio-net: Reporting traffic queue distribution
> statistics through ethtool
>
> On Thu, May 16, 2013 at 01:24:29PM -0700, Sriram Narasimhan wrote:
> > This patch allows virtio-net driver to report traffic distribution
> > to inbound/outbound queues through ethtool -S. The per_cpu
> > virtnet_stats is split into receive and transmit stats and are
> > maintained on a per receive_queue and send_queue basis.
> > virtnet_stats() is modified to aggregate interface level statistics
> > from per-queue statistics. Sample output below:
> >
>
> Thanks for the patch. The idea itself looks OK to me.
> Ben Hutchings already sent some comments
> so I won't repeat them. Some minor more comments
> and questions below.
>
> > NIC statistics:
> > rxq0: rx_packets: 4357802
> > rxq0: rx_bytes: 292642052
> > txq0: tx_packets: 824540
> > txq0: tx_bytes: 55256404
> > rxq1: rx_packets: 0
> > rxq1: rx_bytes: 0
> > txq1: tx_packets: 1094268
> > txq1: tx_bytes: 73328316
> > rxq2: rx_packets: 0
> > rxq2: rx_bytes: 0
> > txq2: tx_packets: 1091466
> > txq2: tx_bytes: 73140566
> > rxq3: rx_packets: 0
> > rxq3: rx_bytes: 0
> > txq3: tx_packets: 1093043
> > txq3: tx_bytes: 73246142
>
> Interesting. This example implies that all packets are coming in
> through the same RX queue - is this right?
> If yes that's worth exploring - could be a tun bug -
> and shows how this patch is useful.
>
> > Signed-off-by: Sriram Narasimhan
>
> BTW, while you are looking at the stats, one other interesting
> thing to add could be checking more types of stats: number of exits,
> queue full errors, etc.
>
> > ---
> > drivers/net/virtio_net.c | 157
> > +-
> > 1 files changed, 128 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 3c23fdc..3c58c52 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -41,15 +41,46 @@ module_param(gso, bool, 0444);
> >
> > #define VIRTNET_DRIVER_VERSION "1.0.0"
> >
> > -struct virtnet_stats {
> > - struct u64_stats_sync tx_syncp;
> > +struct virtnet_rx_stats {
> > struct u64_stats_sync rx_syncp;
> > - u64 tx_bytes;
> > + u64 rx_packets;
> > + u64 rx_bytes;
> > +};
> > +
> > +struct virtnet_tx_stats {
> > + struct u64_stats_sync tx_syncp;
> > u64 tx_packets;
> > + u64 tx_bytes;
> > +};
> >
> > - u64 rx_bytes;
> > - u64 rx_packets;
>
> I think maintaining the stats in a per-queue data structure like this is
> fine. if # of CPUs == # of queues which is typical, we use same amount
[PATCH] ipc,sem: move restart loop to do_smart_update
On Sat, 18 May 2013 15:48:06 +0200 Manfred Spraul wrote: > Hi Rik, > > I like your change to the ipc/sem locking: > A scheme with a per-semaphore lock and without the overhead of always > acquiring both the global and the per-semaphore lock. > > But: > 1) I found one bug with your sem locking changes: > If > - a complex operation is sleeping [would be woken up by update_queue(,-1)] > - a simple op is sleeping > - the success of the simple op would allow the complex op to complete > [i.e.: update_queue(,sem_num) changes the semaphore value to the > value that the complex op waits on] > - an operation wakes up the simple op. Are you referring to eg. a complex operation that waits for several semaphores to turn 0, and a simple op that subtracts 1 from a semaphore, turning it into 0? > then the complex op is not woken up. > > One fix would be a loop in do_smart_update(): > - first check the global queue > - then the per-semaphore queues > - if one of the per-semaphore queues made progress: check the global > queue again > - if the global queue made progress: check the per semaphore queues again > ... Would that be as simple as making do_smart_update() loop back to the top if update_queue on a single semaphore's queue returns a non-zero value (something was changed), and there are complex operations pending? I implemented that in the patch below. > 2) Your patches remove FIFO ordering of the wakeups: > As far as I can see complex ops are now preferred over simple ops. > It's not a bug, noone exept linux implements FIFO. > But the comment it line 28 should be updated > > Should I write a patch, do you want to fix it yourself? You seem to have looked at this problem more closely than I have, so I would appreciate it if you could review this patch :) ---8<--- Subject: ipc,sem: move restart loop to do_smart_update A complex operation may be sleeping on a semaphore to become a certain value. A sleeping simple operation may turn the semaphore into that value. Having the restart loop inside update_queue means we may be missing the complex operation (which lives on a different queue), and result in a semaphore lockup. The lockup can be avoided by moving the restart loop into do_smart_update, so the list of pending complex operations will also be checked if required. Signed-off-by: Rik van Riel Reported-by: Manfred Spraul --- ipc/sem.c | 44 +--- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index a7e40ed..3d71c3c 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -25,8 +25,6 @@ * This file implements System V semaphores. * * User space visible behavior: - * - FIFO ordering for semop() operations (just FIFO, not starvation - * protection) * - multiple semaphore operations that alter the same semaphore in * one semop() are handled. * - sem_ctime (time of last semctl()) is updated in the IPC_SET, SETVAL and @@ -51,8 +49,7 @@ * count_semzcnt() * - the task that performs a successful semop() scans the list of all * sleeping tasks and completes any pending operations that can be fulfilled. - * Semaphores are actively given to waiting tasks (necessary for FIFO). - * (see update_queue()) + * Semaphores are actively given to waiting tasks (see update_queue()). * - To improve the scalability, the actual wake-up calls are performed after * dropping all locks. (see wake_up_sem_queue_prepare(), * wake_up_sem_queue_do()) @@ -68,9 +65,9 @@ * modes for the UNDO variables are supported (per process, per thread) * (see copy_semundo, CLONE_SYSVSEM) * - There are two lists of the pending operations: a per-array list - * and per-semaphore list (stored in the array). This allows to achieve FIFO - * ordering without always scanning all pending operations. - * The worst-case behavior is nevertheless O(N^2) for N wakeups. + * and per-semaphore list (stored in the array). The per-array list is + * used for calls that do multiple semaphore operations in one semop call. + * The worst-case behavior is O(N^2) for N wakeups. */ #include @@ -606,7 +603,7 @@ static void unlink_queue(struct sem_array *sma, struct sem_queue *q) * @sma: semaphore array * @q: the operation that just completed * - * update_queue is O(N^2) when it restarts scanning the whole queue of + * do_smart_update is O(N^2) when it restarts scanning the whole queue of * waiting operations. Therefore this function checks if the restart is * really necessary. It is called after a previously waiting operation * was completed. @@ -671,6 +668,7 @@ static int check_restart(struct sem_array *sma, struct sem_queue *q) * @sma: semaphore array. * @semnum: semaphore that was modified. * @pt: list head for the tasks that must be woken up. + * @restart: did a semop change something that may require a restart? * * update_queue must be called after a semaphore in a semaphore array * was modified. If multipl
Re: [PATCH 1/1] 6lowpan: Fix fragmentation with link-local compressed addresses
Hello, There is a patch which fixes link-local address uncompression: http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1717 I came across a similar solution but didn't submit it as another patch already existed. This patch instead focus on fragmented packet with link-local address compression, which is related but a different bug. 2013/5/19 Alexander Aring : > Hi David, > > can you use a link-layer address on the current net-next kernel? > > I am asking because I can't use a link-layer address currently. > Your patch doesn't help to solve my problem with link-layer addresses. > > > To your patch: > > We get the link-layer addresses from skb not from the allocated > frame->skb. > > Here is the code: > > _saddr = mac_cb(skb)->sa.hwaddr; > _daddr = mac_cb(skb)->da.hwaddr; > > Here is skb != frame->skb so we don't need to copy it to frame->skb->cb > because we already the link-layer addresses from skb->cb. > > Is there another place in the code where we get the link-layer addresses > from allocated "frame" structure? frame->skb is used to reassemble the 6lowpan packet when new fragments are received. This is the 'fragments assembling' switch at the beginning of lowpan_process_data(). It will reassemble fragments until the packet is successfully reassembled. Once it is, skb is replaced: dev_kfree_skb(skb); skb = frame->skb; kfree(frame); And the process continues as with other 6lowpan packets. In particular: _saddr = mac_cb(skb)->sa.hwaddr; _daddr = mac_cb(skb)->da.hwaddr; Several lines later there are: err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix, lowpan_unc_llconf[tmp], skb->data); err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix, lowpan_unc_llconf[tmp], skb->data); These two lines should use _saddr/_daddr instead of skb->data, which fixes the link-local address uncompression. I'm able to use link-layer addresses with these two patches and it works well. > > Regards > Alex Regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv11 2/4] zbud: add to mm/
On Fri, May 17, 2013 at 04:48:37PM +0100, Mel Gorman wrote: > On Mon, May 13, 2013 at 07:40:01AM -0500, Seth Jennings wrote: > > zbud is an special purpose allocator for storing compressed pages. It is > > designed to store up to two compressed pages per physical page. While this > > design limits storage density, it has simple and deterministic reclaim > > properties that make it preferable to a higher density approach when reclaim > > will be used. > > > > zbud works by storing compressed pages, or "zpages", together in pairs in a > > single memory page called a "zbud page". The first buddy is "left > > justifed" at the beginning of the zbud page, and the last buddy is "right > > justified" at the end of the zbud page. The benefit is that if either > > buddy is freed, the freed buddy space, coalesced with whatever slack space > > that existed between the buddies, results in the largest possible free > > region > > within the zbud page. > > > > zbud also provides an attractive lower bound on density. The ratio of zpages > > to zbud pages can not be less than 1. This ensures that zbud can never "do > > harm" by using more pages to store zpages than the uncompressed zpages would > > have used on their own. > > > > This patch adds zbud to mm/ for later use by zswap. > > > > Signed-off-by: Seth Jennings > > I'm not familiar with the code in staging/zcache/zbud.c and this looks > like a rewrite but I'm curious, why was an almost complete rewrite > necessary? The staging code looks like it had debugfs statistics and > the like that would help figure how well the packing was working and so > on. I guess it was probably because it was integrated tightly with other > components in staging but could that not be torn out? I'm guessing you > have a good reason but it'd be nice to see that in the changelog. I'll add a bit about that. > > 4 files changed, 597 insertions(+) > > + * zbud pages are divided into "chunks". The size of the chunks is fixed > > at > > + * compile time and determined by NCHUNKS_ORDER below. Dividing zbud pages > > + * into chunks allows organizing unbuddied zbud pages into a manageable > > number > > + * of unbuddied lists according to the number of free chunks available in > > the > > + * zbud page. > > + * > > Fixing the size of the chunks at compile time is a very strict > limitation! Distributions will have to make that decision for all workloads > that might conceivably use zswap. Having the allocator only deal with pairs > of pages limits the worst-case behaviour where reclaim can generate lots of > IO to free a single physical page. However, the chunk size directly affects > the fragmentation properties, both internal and external, of this thing. > Once NCHUNKS is > 2 it is possible to create a workload that externally > fragments this allocator such that each physical page only holds one > compressed page. If this is a problem for a user then their only option > is to rebuild the kernel which is not always possible. You lost me here. Do you mean NCHUNKS > 2 or NCHUNKS_ORDER > 2? My first guess is that the external fragmentation situation you are referring to is a workload in which all pages compress to greater than half a page. If so, then it doesn't matter what NCHUCNKS_ORDER is, there won't be any pages the compress enough to fit in the < PAGE_SIZE/2 free space that remains in the unbuddied zbud pages. You might also be referring to the fact that if you set NCHUNKS_ORDER to 2 (i.e. there are 4 chunks per zbud page) and you receive an allocation for size (3/4 * PAGE_SIZE) + 1, the allocator will use all 4 chunks for that allocation and the rest of the zbud page is lost to internal fragmentation. That is simply an argument for not choosing a small NCHUNKS_ORDER. > > Please make this configurable by a kernel boot parameter at least. At > a glance it looks like only problem would be that you have to kmalloc > unbuddied[NCHUNKS] in the pool structure but that is hardly of earth > shattering difficulty. Make the variables read_mostly to avoid cache-line > bouncing problems. I am hesitant to make this a tunable without understanding why anyone would want to tune it. It's hard to convey to a user what this tunable would do and what effect it might have. I'm not saying that isn't such a situation. I just don't see one didn't understand your case above. > > Finally, because a review would never be complete without a bitching > session about names -- I don't like the name zbud. Buddy allocators take > a large block of memory and split it iteratively (by halves for binary > buddy allocators but there are variations) until it's a best fit for the > allocation request. A key advantage of such schemes is fast searching for > free holes. That's not what this allocator does and as the page allocator > is a binary buddy allocator in Linux, calling this this a buddy allocator > is a bit misleading. Looks like the existing zbud.c also has this problem > but hey. This t
