Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.
Herbert Xu wrote:
> On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
> >
> > However, when I have the library and generic algorithm compiled in,
> > I do not see the PCLMULQDQ version loaded.
> >
> > CONFIG_CRYPTO_CRCT10DIF=y
> > CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> > CONFIG_CRC_T10DIF=y
>
> That is completely expected. I don't really think we need to
> do anything about this case. After all, if the admin wants to
> use the optimised version for CRC_T10DIF then they could simply
> compile that in as well.
>
Wow! ;-)
But I'd expect something like
static int __init crc_t10dif_mod_init(void)
{
+#if !defined(CONFIG_CRC_T10DIF_MODULE) &&
defined(CONFIG_CRYPTO_CRCT10DIF_PCLMUL_MODULE)
+ printk(KERN_WARNING "Consider CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y for
better performance\n");
+#endif
crct10dif_tfm = crypto_alloc_shash("crct10dif", 0, 0);
return PTR_RET(crct10dif_tfm);
}
because the admin might not be aware of this implication.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of: provide of_platform_unpopulate()
Hello Sebastian,
I just did one more testing.
In case of iio/adc/exynos_adc.c there is a bug in the remove path.
If I fix the bug in the driver, with below patch
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -375,14 +375,14 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(>dev, NULL,
- exynos_adc_remove_devices);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
writel(0, info->enable_reg);
iio_device_unregister(indio_dev);
free_irq(info->irq, info);
iio_device_free(indio_dev);
+ device_for_each_child(>dev, NULL,
+ exynos_adc_remove_devices);
Even without your fix, I could configure it as a module and the rmmod, insmod
are working fine. (no crash)
Regards,
Naveen
--- Original Message ---
Sender : Sebastian Andrzej Siewior
Date : Jul 19, 2013 23:44 (GMT+05:30)
Title : [PATCH] of: provide of_platform_unpopulate()
So I called of_platform_populate() on a device to get each child device
probed and on rmmod and I need to reverse its doing. After a quick grep
I did what others did as well and rmmod ended in:
| Unable to handle kernel NULL pointer dereference at virtual address 0018
| PC is at release_resource+0x18/0x80
| Process rmmod (pid: 2005, stack limit = 0xedc30238)
| [] (release_resource+0x18/0x80) from []
(platform_device_del+0x78/0xac)
| [] (platform_device_del+0x78/0xac) from []
(platform_device_unregister+0xc/0x18)
The problem is that platform_device_del() "releases" each ressource in its
tree. This does not work on platform_devices created by OF becuase they
were never added via insert_resource(). As a consequence old->parent in
__release_resource() is NULL and we explode while accessing ->child.
So I either I do something completly wrong _or_ nobody here tested the
rmmod path of their driver.
This patch provides a common function to unregister / remove devices
which added to the system via of_platform_populate(). While this works
now on my test case I have not tested any of the driver I modify here so
feedback is greatly appreciated.
Cc: Tony Lindgren
Cc: Doug Anderson
Cc: Vivek Gautam
Cc: Naveen Krishna Chatradhi
Cc: Kukjin Kim
Cc: Kishon Vijay Abraham I
Cc: Roger Quadros
Cc: George Cherian
Cc: Felipe Balbi
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/bus/omap-ocp2scp.c | 13 ++---
drivers/iio/adc/exynos_adc.c | 15 ++-
drivers/mfd/omap-usb-host.c| 9 +
drivers/of/platform.c | 22 ++
drivers/usb/dwc3/dwc3-exynos.c | 11 +--
drivers/usb/dwc3/dwc3-omap.c | 12 +---
include/linux/of_platform.h| 4
7 files changed, 33 insertions(+), 53 deletions(-)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 5511f98..510bb9e 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -23,15 +23,6 @@
#include
#include
-static int ocp2scp_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static int omap_ocp2scp_probe(struct platform_device *pdev)
{
int ret;
@@ -51,7 +42,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
return 0;
err0:
- device_for_each_child(>dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(>dev);
return ret;
}
@@ -59,7 +50,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
static int omap_ocp2scp_remove(struct platform_device *pdev)
{
pm_runtime_disable(>dev);
- device_for_each_child(>dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(>dev);
return 0;
}
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 9809fc9..10248e1 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -216,15 +216,6 @@ static const struct iio_chan_spec
exynos_adc_iio_channels[] = {
ADC_CHANNEL(9, "adc9"),
};
-static int exynos_adc_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
@@ -357,8 +348,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(>dev, NULL,
- exynos_adc_remove_devices);
+ of_platform_unpopulate(>dev);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
err_iio_dev:
@@ -375,8 +365,7 @@ static int exynos_adc_remove(struct platform_device
Re: /proc/timer_list and weird behavior with dropbear
On Fri, Jul 19, 2013 at 03:37:07PM -0500, Nathan Zimmer wrote: > Forgot the patch last time. > Sorry yes, this appears to fix the problem I experience. thanks holger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote: > > However, when I have the library and generic algorithm compiled in, > I do not see the PCLMULQDQ version loaded. > > CONFIG_CRYPTO_CRCT10DIF=y > CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m > CONFIG_CRC_T10DIF=y That is completely expected. I don't really think we need to do anything about this case. After all, if the admin wants to use the optimised version for CRC_T10DIF then they could simply compile that in as well. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bridge: do not call setup_timer() multiple times
From: Eric Dumazet
Date: Fri, 19 Jul 2013 20:07:16 -0700
> From: Eric Dumazet
>
> commit 9f00b2e7cf24 ("bridge: only expire the mdb entry when query is
> received") added a nasty bug as an active timer can be reinitialized.
>
> setup_timer() must be done once, no matter how many time mod_timer()
> is called. br_multicast_new_group() is the right place to do this.
>
> Reported-by: Srivatsa S. Bhat
> Diagnosed-by: Thomas Gleixner
> Signed-off-by: Eric Dumazet
> Tested-by: Srivatsa S. Bhat
> Cc: Cong Wang
Applied, thanks a lot Eric.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of: provide of_platform_unpopulate()
Hello Sebastian,
--- Original Message ---
Sender : Sebastian Andrzej Siewior
Date : Jul 19, 2013 23:44 (GMT+05:30)
Title : [PATCH] of: provide of_platform_unpopulate()
So I called of_platform_populate() on a device to get each child device
probed and on rmmod and I need to reverse its doing. After a quick grep
I did what others did as well and rmmod ended in:
| Unable to handle kernel NULL pointer dereference at virtual address 0018
| PC is at release_resource+0x18/0x80
| Process rmmod (pid: 2005, stack limit = 0xedc30238)
| [] (release_resource+0x18/0x80) from []
(platform_device_del+0x78/0xac)
| [] (platform_device_del+0x78/0xac) from []
(platform_device_unregister+0xc/0x18)
The problem is that platform_device_del() "releases" each ressource in its
tree. This does not work on platform_devices created by OF becuase they
were never added via insert_resource(). As a consequence old->parent in
__release_resource() is NULL and we explode while accessing ->child.
So I either I do something completly wrong _or_ nobody here tested the
rmmod path of their driver.
This patch provides a common function to unregister / remove devices
which added to the system via of_platform_populate(). While this works
now on my test case I have not tested any of the driver I modify here so
feedback is greatly appreciated.
I've tested this on the exynos_adc driver under iio/adc/
and found a bug in the driver. When I fix the bug, your change happily rmmods
the module.
Will send the patch separately.
Thanks for pointing out the bug for me.
Cc: Tony Lindgren
Cc: Doug Anderson
Cc: Vivek Gautam
Cc: Naveen Krishna Chatradhi
Cc: Kukjin Kim
Cc: Kishon Vijay Abraham I
Cc: Roger Quadros
Cc: George Cherian
Cc: Felipe Balbi
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/bus/omap-ocp2scp.c | 13 ++---
drivers/iio/adc/exynos_adc.c | 15 ++-
drivers/mfd/omap-usb-host.c| 9 +
drivers/of/platform.c | 22 ++
drivers/usb/dwc3/dwc3-exynos.c | 11 +--
drivers/usb/dwc3/dwc3-omap.c | 12 +---
include/linux/of_platform.h| 4
7 files changed, 33 insertions(+), 53 deletions(-)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 5511f98..510bb9e 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -23,15 +23,6 @@
#include
#include
-static int ocp2scp_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static int omap_ocp2scp_probe(struct platform_device *pdev)
{
int ret;
@@ -51,7 +42,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
return 0;
err0:
- device_for_each_child(>dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(>dev);
return ret;
}
@@ -59,7 +50,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
static int omap_ocp2scp_remove(struct platform_device *pdev)
{
pm_runtime_disable(>dev);
- device_for_each_child(>dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(>dev);
return 0;
}
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 9809fc9..10248e1 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -216,15 +216,6 @@ static const struct iio_chan_spec
exynos_adc_iio_channels[] = {
ADC_CHANNEL(9, "adc9"),
};
-static int exynos_adc_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
@@ -357,8 +348,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(>dev, NULL,
- exynos_adc_remove_devices);
+ of_platform_unpopulate(>dev);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
err_iio_dev:
@@ -375,8 +365,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(>dev, NULL,
- exynos_adc_remove_devices);
+ of_platform_unpopulate(>dev);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
writel(0, info->enable_reg);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..bb26cea 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -832,13 +832,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return ret;
}
-static int usbhs_omap_remove_child(struct device *dev, void *data)
-{
- dev_info(dev,
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
On Fri, 2013-07-19 at 14:01 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2013-07-19 at 08:33 -0700, James Bottomley wrote:
> > On Thu, 2013-07-18 at 23:34 -0700, Nicholas A. Bellinger wrote:
> > > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> > > index 0101af5..191bc15 100644
> > > --- a/drivers/ata/libata-scsi.c
> > > +++ b/drivers/ata/libata-scsi.c
> > > @@ -1144,7 +1144,11 @@ static int ata_scsi_dev_config(struct scsi_device
> > > *sdev,
> > > "sector_size=%u > PAGE_SIZE, PIO may
> > > malfunction\n",
> > > sdev->sector_size);
> > >
> > > - blk_queue_update_dma_alignment(q, sdev->sector_size - 1);
> > > + if (!q->mq_ops) {
> > > + blk_queue_update_dma_alignment(q, sdev->sector_size - 1);
> > > + } else {
> > > + printk("Skipping dma_alignment for libata w/ scsi-mq\n");
> > > + }
> >
> > Amazingly enough there is a reason for the dma alignment, and it wasn't
> > just to annoy you, so you can't blindly do this.
> >
> > The email thread is probably lost in the mists of time, but if I
> > remember correctly the problem is that some ahci DMA controllers barf if
> > the sector they're doing DMA on crosses a page boundary. Some are
> > annoying enough to actually cause silent data corruption. You won't
> > find every ahci DMA controller doing this, so the change will work for
> > some, but it will be hard to identify those it won't work for until
> > people start losing data.
>
> Thanks for the extra background.
>
> So at least from what I gather thus far this shouldn't be an issue for
> initial testing with scsi-mq <-> libata w/ ata_piix.
>
> >
> > The correct fix, obviously, is to do the bio copy on the kernel path for
> > unaligned data. It is OK to assume that REQ_TYPE_FS data is correctly
> > aligned (because of the block to page alignment).
> >
>
> Indeed. Looking into the bio_copy_kern() breakage next..
>
OK, after further investigation the root cause is a actually a missing
bio->bio_end_io() -> bio_copy_kern_endio() -> bio_put() from the
blk_end_sync_rq() callback path that scsi-mq REQ_TYPE_BLOCK_PC is
currently using.
Including the following patch into the scsi-mq working branch now, and
reverting the libata dma_alignment=0x03 hack.
Alexander, care to give this a try..?
--nab
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 0761c89..70303d2 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -25,7 +25,10 @@ static void blk_end_sync_rq(struct request *rq, int error)
struct completion *waiting = rq->end_io_data;
rq->end_io_data = NULL;
- if (!rq->q->mq_ops) {
+ if (rq->q->mq_ops) {
+ if (rq->bio)
+ bio_endio(rq->bio, error);
+ } else {
__blk_put_request(rq->q, rq);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
> > Effects of this are probably limited to failure of EHABI unwinding when
> > starting from a function that uses r7 to restore its stack pointer, but
> > the possibility for further breakage (which would be invisible on
> > non-Thumb kernels) is worrying.
[...]
> I'm struggling to understand exactly the problem that this patch is trying
> to address. If it's just a code consistency issue, I don't think it's worth
> it (I actually find it less confusing the way we currently have things) but
> if there is a real bug, perhaps you could provide a testcase?
There is a real bug here, but my commit message wasn't very clear. This
was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
(with my other recently posted patch applied), because kernel/sched.c is
built with -fno-omit-frame-pointer (which is wrong, but that's a problem
for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
and somewhere along the line the unwinder gets the r11 value instead.
This would also apply to any function with a variable-length array, but
__schedule happens to have the perf hook I was trying to use.
I should add that this bug doesn't affect me directly at the moment,
because we're not currently using CONFIG_THUMB2_KERNEL on Firefox OS,
because our kernels are assorted older versions with hardware vendors'
changes and there are some issues with it. But I felt it was worth
tracking this down before trying to send changes upstream.
The "right" thing to do here might be to just include all the registers,
or at least {r4-pc}, in struct stackframe. The parts that aren't {fp,
sp, lr, pc} could be ifdef'ed if we're concerned enough about the
overhead in kernels using APCS frame pointer unwinding.
I agree that a test case would be good -- I'm more than a little worried
of regressions without one -- but I could use some advice on how best to
do that.
--Jed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] EDAC: Fix lockdep splat
Em Fri, 19 Jul 2013 12:28:25 +0200
Borislav Petkov escreveu:
> From: Borislav Petkov
>
> Fix the following:
>
> BUG: key 88043bdd0330 not in .data!
> [ cut here ]
> WARNING: at kernel/lockdep.c:2987 lockdep_init_map+0x565/0x5a0()
> DEBUG_LOCKS_WARN_ON(1)
> Modules linked in: glue_helper sb_edac(+) edac_core snd acpi_cpufreq lrw
> gf128mul ablk_helper iTCO_wdt evdev i2c_i801 dcdbas button cryptd pcspkr
> iTCO_vendor_support usb_common lpc_ich mfd_core soundcore mperf processor
> microcode
> CPU: 2 PID: 599 Comm: modprobe Not tainted 3.10.0 #1
> Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013
> 0009 880439a1d920 8160a9a9 880439a1d958
> 8103d9e0 88043af4a510 81a16e11
> 88043bdd0330 880439a1d9b8 8103dacc
> Call Trace:
> dump_stack
> warn_slowpath_common
> warn_slowpath_fmt
> lockdep_init_map
> ? trace_hardirqs_on_caller
> ? trace_hardirqs_on
> debug_mutex_init
> __mutex_init
> bus_register
> edac_create_sysfs_mci_device
> edac_mc_add_mc
> sbridge_probe
> pci_device_probe
> driver_probe_device
> __driver_attach
> ? driver_probe_device
> bus_for_each_dev
> driver_attach
> bus_add_driver
> driver_register
> __pci_register_driver
> ? 0xa0010fff
> sbridge_init
> ? 0xa0010fff
> do_one_initcall
> load_module
> ? unset_module_init_ro_nx
> SyS_init_module
> tracesys
> ---[ end trace d24a70b0d3ddf733 ]---
> EDAC MC0: Giving out device to 'sbridge_edac.c' 'Sandy Bridge Socket#0': DEV
> :3f:0e.0
> EDAC sbridge: Driver loaded.
>
> What happens is that bus_register needs a statically allocated lock_key
> because the last is handed in to lockdep. However, struct mem_ctl_info
> embeds struct bus_type (the whole struct, not a pointer to it) and the
> whole thing gets dynamically allocated.
>
> Fix this by using a statically allocated struct bus_type for the MC bus.
>
> Cc: Mauro Carvalho Chehab
Acked-by: Mauro Carvalho Chehab
But see below.
> Cc: Markus Trippelsdorf
> Signed-off-by: Borislav Petkov
> ---
> drivers/edac/edac_mc.c | 9 +
> drivers/edac/edac_mc_sysfs.c | 28 +++-
> drivers/edac/i5100_edac.c| 2 +-
> include/linux/edac.h | 7 ++-
> 4 files changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
> index 27e86d938262..c55ad285c285 100644
> --- a/drivers/edac/edac_mc.c
> +++ b/drivers/edac/edac_mc.c
> @@ -48,6 +48,8 @@ static LIST_HEAD(mc_devices);
> */
> static void const *edac_mc_owner;
>
> +static struct bus_type mc_bus[EDAC_MAX_MCS];
> +
> unsigned edac_dimm_info_location(struct dimm_info *dimm, char *buf,
>unsigned len)
> {
> @@ -723,6 +725,11 @@ int edac_mc_add_mc(struct mem_ctl_info *mci)
> int ret = -EINVAL;
> edac_dbg(0, "\n");
>
> + if (mci->mc_idx >= EDAC_MAX_MCS) {
> + pr_warn_once("Too many memory controllers: %d\n", mci->mc_idx);
> + return ret;
Hmm... while I'm ok with returning -EINVAL, maybe instead it could be
returning some other error more meaningful error code (ENODEV?).
> + }
> +
> #ifdef CONFIG_EDAC_DEBUG
> if (edac_debug_level >= 3)
> edac_mc_dump_mci(mci);
> @@ -762,6 +769,8 @@ int edac_mc_add_mc(struct mem_ctl_info *mci)
> /* set load time so that error rate can be tracked */
> mci->start_time = jiffies;
>
> + mci->bus = _bus[mci->mc_idx];
> +
> if (edac_create_sysfs_mci_device(mci)) {
> edac_mc_printk(mci, KERN_WARNING,
> "failed to create sysfs device\n");
> diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
> index ef15a7e613bc..e7c32c4f7837 100644
> --- a/drivers/edac/edac_mc_sysfs.c
> +++ b/drivers/edac/edac_mc_sysfs.c
> @@ -370,7 +370,7 @@ static int edac_create_csrow_object(struct mem_ctl_info
> *mci,
> return -ENODEV;
>
> csrow->dev.type = _attr_type;
> - csrow->dev.bus = >bus;
> + csrow->dev.bus = mci->bus;
> device_initialize(>dev);
> csrow->dev.parent = >dev;
> csrow->mci = mci;
> @@ -605,7 +605,7 @@ static int edac_create_dimm_object(struct mem_ctl_info
> *mci,
> dimm->mci = mci;
>
> dimm->dev.type = _attr_type;
> - dimm->dev.bus = >bus;
> + dimm->dev.bus = mci->bus;
> device_initialize(>dev);
>
> dimm->dev.parent = >dev;
> @@ -975,11 +975,13 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
> *mci)
>* The memory controller needs its own bus, in order to avoid
>* namespace conflicts at /sys/bus/edac.
>*/
> - mci->bus.name = kasprintf(GFP_KERNEL, "mc%d", mci->mc_idx);
> - if (!mci->bus.name)
> + mci->bus->name = kasprintf(GFP_KERNEL, "mc%d", mci->mc_idx);
> + if (!mci->bus->name)
> return -ENOMEM;
Re: [PATCH] ARM: perf: Implement perf_arch_fetch_caller_regs
On Mon, Jul 15, 2013 at 02:53:42PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:17:14AM +0100, Jed Davis wrote:
[...]
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define perf_arch_fetch_caller_regs(regs, ip)
> > \
> > + do {\
> > + __u32 _cpsr, _pc; \
> > + __asm__ __volatile__("str r7, [%[_regs], #(7 * 4)]\n\t" \
> > +"str r13, [%[_regs], #(13 * 4)]\n\t" \
> > +"str r14, [%[_regs], #(14 * 4)]\n\t" \
>
> Is this safe? How can we be sure that the registers haven't been clobbered
> by the callee before this macro is expanded? For example, you can end up
> with the following code:
They might be clobbered, but if they are, then...
> 0058 :
> 58: e92d 43f0 stmdb sp!, {r4, r5, r6, r7, r8, r9, lr}
> 5c: b09bsub sp, #108; 0x6c
> 5e: ac08add r4, sp, #32
> 60: 4681mov r9, r0
> 62: 4688mov r8, r1
> 64: 4620mov r0, r4
> 66: 2148movsr1, #72 ; 0x48
> 68: f7ff fffe bl 0 <__memzero>
> 6c: 61e7str r7, [r4, #28]
> 6e: f8c4 d034 str.w sp, [r4, #52] ; 0x34
> 72: f8c4 e038 str.w lr, [r4, #56] ; 0x38
>
> but the call to __memzero will have corrupted the lr.
...the function's unwinding entry will restore them from the stack, and
can't assume anything about their values before then. It's the same
problem as if the code was interrupted by a profiler timer at that point
and we tried unwinding from the trap state.
Hopefully. It's hard to be as rigorous as I'd like about this, because
the Exception Handling ABI was meant for exception handling, so as
specified it only needs to work at points where C++ exceptions can be
thrown, as I understand it. Fortunately GCC isn't limited to that, but
there are more issues, because -fasynchronous-unwind-tables doesn't
actually make things work from *any* instruction as documented (which is
not entirely bad, because working correctly would significantly increase
the size of .extab/.exidx).
All that said, the unwinding program for a function should work at any
point after the prologue and before the epilogue.
> > +"mov %[_pc], r15\n\t" \
> > +"mrs %[_cpsr], cpsr\n\t" \
> > +: [_cpsr] "=r" (_cpsr),\
> > + [_pc] "=r" (_pc) \
> > +: [_regs] "r" (&(regs)->uregs) \
>
> It would be cleaner to pass a separate argument for each register, using the
> ARM_rN macros rather than calculating the offset by hand.
I'll do that. If there were more arguments there might be a problem
at -O0, because the naive translation can run out of registers in
some cases, but that shouldn't be a problem here. (Nor if someone
later extends this to all the core registers, because {r0-r13} can and
presumably should use a store-multiple.)
Thanks for the quick review, and sorry for the delay in responding.
--Jed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] arm: dts: Add USB phy nodes for AM33XX
On 7/20/2013 12:12 AM, Sebastian Andrzej Siewior wrote:
On 07/19/2013 08:33 PM, Sergei Shtylyov wrote:
Hello.
Hello,
usb: usb@4740 {
compatible = "ti,am33xx-usb";
usb0_phy: phy@47401300 {
compatible = "ti,am335x-usb-phy";
}
usb0: usb@47401000 {
musb0: usb@47401400 {
compatible = "mg,musbmhdrc";
}
}
usb1_phy: phy@47402300 {
compatible = "ti,am335x-usb-phy";
}
usb1: usb@47402000 {
musb1: usb@47402400 {
compatible = "mg,musbmhdrc";
}
}
}
And you want usb0_phy to be child of usb0? In the TRM they are all in
the same block.
Ah, the fact that PHYs didn't have the "reg" property got me muddled,
I didn't pay attention to the address part of the node names... BTW,
where is the "reg" prop?
I skipped it for the general idea. I planned to repost is today but I
messed up dsps and need to get it working first…
I see PHYs share the address space with
"omap-control-usb@44e10620" device -- what's the point with this?
I decided to get rid of this. Both phys have 8 bytes (2 registers)
which are exclusive for them.
There is one register for the wakeup which is shared by both.
I changed this to limit it only to the 8bytes per phy. I care about
wakeup later - hopefully George will take care of this :)
But for wakeup how can we map it since its the same register. That is
the main reason i took the
omap-control-usb route.
Sebastian
WBR, Sergei
Sebastian
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] arm: dts: Add USB phy nodes for AM33XX
On 7/20/2013 12:03 AM, Sergei Shtylyov wrote:
Hello.
On 07/19/2013 06:20 PM, Sebastian Andrzej Siewior wrote:
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..e3890c4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -326,21 +326,59 @@
status = "disabled";
};
-usb@4740 {
-compatible = "ti,musb-am33xx";
-reg = <0x4740 0x1000/* usbss */
- 0x47401000 0x800/* musb instance 0 */
- 0x47401800 0x800>;/* musb instance 1 */
-interrupts = <17/* usbss */
- 18/* musb instance 0 */
- 19>;/* musb instance 1 */
-multipoint = <1>;
-num-eps = <16>;
-ram-bits = <12>;
-port0-mode = <3>;
-port1-mode = <3>;
-power = <250>;
-ti,hwmods = "usb_otg_hs";
+phy1: am335x-usb0@44e10620 {
Shouldn't the PHYs be *under* the usb0/1 device nodes in the
hierarchy?
They're not on the same bus as the MUSB controllers for sure.
I redo the complete thing. I have now:
usb: usb@4740 {
compatible = "ti,am33xx-usb";
usb0_phy: phy@47401300 {
compatible = "ti,am335x-usb-phy";
}
usb0: usb@47401000 {
musb0: usb@47401400 {
compatible = "mg,musbmhdrc";
}
}
usb1_phy: phy@47402300 {
compatible = "ti,am335x-usb-phy";
}
usb1: usb@47402000 {
musb1: usb@47402400 {
compatible = "mg,musbmhdrc";
}
}
}
And you want usb0_phy to be child of usb0? In the TRM they are all in
the same block.
Ah, the fact that PHYs didn't have the "reg" property got me
muddled, I didn't pay attention to the address part of the node
names... BTW, where is the "reg" prop? I see PHYs share the address
space with "omap-control-usb@44e10620" device -- what's the point with
this?
In control module(CM) each USB has got 2 registers in which one is a
shared register( wakeup register)
So all the CM access are done using the control-usb driver
(phy-omap-control-usb.c). Same reason why phy's dont have a reg property.
Sebastian
WBR, Sergei
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] backports: backport drvdata = NULL core driver fixes
On Fri, 19 Jul 2013, Luis R. Rodriguez wrote: > Thanks Julia. In that case I'm going to just leave this in place given > that if there's a bug upstream we'll get it fixed as soon as a > respective patch gets upstream as well. That is, we are not using old > drivers, we use the same upstream drivers so if a regression was found > in backports the fix must go upstream s well. This is one of the > benefits of backporting -- the range of users and testers increases > and we still benefit from the upstream bandwagon. I don't understand. If you're not using old drivers, and you incorporate all the upstream patches, then what's the difference between a backport and the current kernel? In fact, if you're incorporating all the upstream driver patches, then why haven't you already got the drvdata change? As one example of the sort of subtle problem exposed by the drvdata change, take a look at commit b2ca69907657. For more examples, see commits bf90ff5f3b8f, 638b9e15233c, 51ef847df746, 289b076f89c2, 53636555b919, 99a6f73c495c, 003615302a16, 94ab71ce2889, 3124d1d71d3d, c27f3efc5608, 95940a04bfe8, 5c1a0f418d8d, db5c8b52, 8bf769eb5f6e, 4295fe7791a1, fa919751a2d2, a9556040119a, 7bdce71822f4, and a1028f0abfb3. Admittedly, these are all related problems in a single subsystem, but it gives you a little idea of how far this goes. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next-3.11][PATCH 1/2] tracing: Kill trace_array->waiter
From: Oleg Nesterov
Trivial. trace_array->waiter has no users since 6eaaa5d5
"tracing/core: use appropriate waiting on trace_pipe".
Link: http://lkml.kernel.org/r/20130719142036.ga1...@redhat.com
Signed-off-by: Oleg Nesterov
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.h |1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 57b7bb0..e7d643b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -214,7 +214,6 @@ struct trace_array {
struct dentry *event_dir;
struct list_headsystems;
struct list_headevents;
- struct task_struct *waiter;
int ref;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next-3.11][PATCH 2/2] tracing: Kill the unbalanced tr->ref++ in tracing_buffers_open()
From: Oleg Nesterov tracing_buffers_open() does trace_array_get() and then it wrongly inrcements tr->ref again under trace_types_lock. This means that every caller leaks trace_array: # cd /sys/kernel/debug/tracing/ # mkdir instances/X # true < instances/X/per_cpu/cpu0/trace_pipe_raw # rmdir instances/X rmdir: failed to remove `instances/X': Device or resource busy Link: http://lkml.kernel.org/r/20130719153644.ga18...@redhat.com Cc: Ingo Molnar Cc: Frederic Weisbecker Cc: Masami Hiramatsu Cc: sta...@vger.kernel.org # 3.10 Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt --- kernel/trace/trace.c |2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 7d9ceab..3f24777 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -4959,8 +4959,6 @@ static int tracing_buffers_open(struct inode *inode, struct file *filp) mutex_lock(_types_lock); - tr->ref++; - info->iter.tr = tr; info->iter.cpu_file = tc->cpu; info->iter.trace= tr->current_trace; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next-3.11][PATCH 0/2] tracing: A couple more fixes
Oleg sent me a couple more fixes. Pushing them into my for-next branch. Monday I'll push to Linus. -- Steve git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: e70e78e3c83b536730e31231dd9b979768d8df3c 1bb539ca36e21c2f4fce0865e11df384bc7b7656 Oleg Nesterov (2): tracing: Kill trace_array->waiter tracing: Kill the unbalanced tr->ref++ in tracing_buffers_open() kernel/trace/trace.c |2 -- kernel/trace/trace.h |1 - 2 files changed, 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi, On Saturday 20 July 2013 05:20 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:59 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:13 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: + ret = dev_set_name(>dev, "%s.%d", dev_name(dev), id); Your naming is odd, no "phy" anywhere in it? You rely on the sender to never send a duplicate name.id pair? Why not create your own ids based on the number of phys in the system, like almost all other classes and subsystems do? hmm.. some PHY drivers use the id they provide to perform some of their internal operation as in [1] (This is used only if a single PHY provider implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO to give the PHY drivers an option to use auto id. [1] -> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, who cares about the id? No one outside of the phy core ever should, because you pass back the only pointer that they really do care about, if they need to do anything with the device. Use that, and then you can hmm.. ok. rip out all of the "search for a phy by a string" logic, as that's not Actually this is needed for non-dt boot case. In the case of dt boot, we use a phandle by which the controller can get a reference to the phy. But in the case of non-dt boot, the controller can get a reference to the phy only by label. I don't understand. They registered the phy, and got back a pointer to it. Why can't they save it in their local structure to use it again later if needed? They should never have to "ask" for the device, as the One is a *PHY provider* driver which is a driver for some PHY device. This will use phy_create to create the phy. The other is a *PHY consumer* driver which might be any controller driver (can be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot). device id might be unknown if there are multiple devices in the system. I agree with you on the device id part. That need not be known to the PHY driver. How does a consumer know which "label" to use in a non-dt system if there are multiple PHYs in the system? That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a "name". I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/15] drivers: phy: add generic PHY framework
Hi, On Friday 19 July 2013 09:24 PM, Stephen Warren wrote: On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:59 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:13 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: + ret = dev_set_name(>dev, "%s.%d", dev_name(dev), id); Your naming is odd, no "phy" anywhere in it? You rely on the sender to never send a duplicate name.id pair? Why not create your own ids based on the number of phys in the system, like almost all other classes and subsystems do? hmm.. some PHY drivers use the id they provide to perform some of their internal operation as in [1] (This is used only if a single PHY provider implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO to give the PHY drivers an option to use auto id. [1] -> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, who cares about the id? No one outside of the phy core ever should, because you pass back the only pointer that they really do care about, if they need to do anything with the device. Use that, and then you can hmm.. ok. rip out all of the "search for a phy by a string" logic, as that's not Actually this is needed for non-dt boot case. In the case of dt boot, we use a phandle by which the controller can get a reference to the phy. But in the case of non-dt boot, the controller can get a reference to the phy only by label. I don't understand. They registered the phy, and got back a pointer to it. Why can't they save it in their local structure to use it again later if needed? They should never have to "ask" for the device, as the One is a *PHY provider* driver which is a driver for some PHY device. This will use phy_create to create the phy. The other is a *PHY consumer* driver which might be any controller driver (can be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot). device id might be unknown if there are multiple devices in the system. I agree with you on the device id part. That need not be known to the PHY driver. How does a consumer know which "label" to use in a non-dt system if there are multiple PHYs in the system? That should be passed using platform data. I don't think that's right. That's just like passing clock names in platform data, which I believe is frowned upon. Instead, why not take the approach that e.g. regulators have taken? Each driver defines the names of the objects that it requires. There is a table (registered by a board file) that has lookup key (device name, We were using a similar approach with USB PHY layer but things started breaking after the device names are created using PLATFORM_DEVID_AUTO. Now theres no way to reliably know the device names in advance. Btw I had such device name binding in my v3 of this patch series [1] and had some discussion with Grant during that time [2]. [1] -> http://archive.arm.linux.org.uk/lurker/message/20130320.091200.721a6fb5.hu.html [2] -> https://lkml.org/lkml/2013/4/22/26 Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bridge: do not call setup_timer() multiple times
From: Eric Dumazet
commit 9f00b2e7cf24 ("bridge: only expire the mdb entry when query is
received") added a nasty bug as an active timer can be reinitialized.
setup_timer() must be done once, no matter how many time mod_timer()
is called. br_multicast_new_group() is the right place to do this.
Reported-by: Srivatsa S. Bhat
Diagnosed-by: Thomas Gleixner
Signed-off-by: Eric Dumazet
Tested-by: Srivatsa S. Bhat
Cc: Cong Wang
---
net/bridge/br_multicast.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 69af490..4b99c9a 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -619,6 +619,9 @@ rehash:
mp->br = br;
mp->addr = *group;
+ setup_timer(>timer, br_multicast_group_expired,
+ (unsigned long)mp);
+
hlist_add_head_rcu(>hlist[mdb->ver], >mhash[hash]);
mdb->size++;
@@ -1126,7 +1129,6 @@ static int br_ip4_multicast_query(struct net_bridge *br,
if (!mp)
goto out;
- setup_timer(>timer, br_multicast_group_expired, (unsigned long)mp);
mod_timer(>timer, now + br->multicast_membership_interval);
mp->timer_armed = true;
@@ -1204,7 +1206,6 @@ static int br_ip6_multicast_query(struct net_bridge *br,
if (!mp)
goto out;
- setup_timer(>timer, br_multicast_group_expired, (unsigned long)mp);
mod_timer(>timer, now + br->multicast_membership_interval);
mp->timer_armed = true;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
> On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> > On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> > > Alas, this is not the one I'd like to apply.
> > >
> > > With that patch applied, new device objects are created to avoid binding
> > > the
> > > processor driver directly to the cpu system device objects, because that
> > > apparently confuses udev and it starts to ignore the cpu modalias once the
> > > driver has been bound to any of those objects.
> > >
> > > I've verified in the meantime that this indeed is the case.
> > >
> > > A link to the patch in question:
> > > https://patchwork.kernel.org/patch/2830561/
> > >
> > > Greg, I asked you some time ago whether or not it was possible for udev
> > > to stop
> > > autoloading modules that matched the cpu modalias after a driver had been
> > > bound
> > > to the cpu system device objects and you said "no". However, this time I
> > > can
> > > say with certainty that that really is the case. So, the question now is
> > > whether or not we can do anything in the kernel to avoid that confusion
> > > in udev
> > > instead of applying the patch linked above (which is beyond ugly in my
> > > not so
> > > humble opinion)?
> >
> > udev isn't doing any module loading, 'modprobe' is just being called for
> > any new module alias that shows up in the system, and all of the drivers
> > that match it then get loaded.
>
> The problem is that that doesn't happen when a driver is bound to the
> cpu system device objects. modprobe is just not called for modules that
> match the cpu modalias in that case.
>
> If I call modprobe manually for any of the modules in question, it loads
> and works no problem.
OK, I know what's up. udev has no rule that would allow it to load stuff on
the basis of MODALIAS if DRIVER is set in the event properties.
So, the following rule needs to be added to udev rules for things to work
as before:
DRIVER=="processor", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load
$env{MODALIAS}"
To be precise, I added a file called 80-drivers.rules to /etc/udev/rules.d/
with the following contents:
ACTION=="remove", GOTO="drivers_end"
DRIVER=="processor", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load
$env{MODALIAS}"
LABEL="drivers_end"
but I'm not sure how to propagate this to the udev maintainers.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: key ffff880c1148c478 not in .data! (V3.10.0)
Em Fri, 19 Jul 2013 01:27:18 +0200
Borislav Petkov escreveu:
> On Thu, Jul 18, 2013 at 04:51:48PM +, Luck, Tony wrote:
> > + BUG_ON(mci->mc_idx >= EDAC_MAX_MCS);
> >
> > Do we have to "BUG_ON()" here? Couldn't we be gentler with something like:
> >
> > if (mci->mc_idx >= EDAC_MAX_MCS) {
> > printk_once(KERN_WARNING "Too many memory controllers\n");
> > return; /* probably need to make sure caller copes with this
> > ... so more stuff there */
>
> Yeah, we can do something like this:
With this change, the patch looks ok for me.
Acked-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
> index 429e971e02d7..c55ad285c285 100644
> --- a/drivers/edac/edac_mc.c
> +++ b/drivers/edac/edac_mc.c
> @@ -725,6 +725,11 @@ int edac_mc_add_mc(struct mem_ctl_info *mci)
> int ret = -EINVAL;
> edac_dbg(0, "\n");
>
> + if (mci->mc_idx >= EDAC_MAX_MCS) {
> + pr_warn_once("Too many memory controllers: %d\n", mci->mc_idx);
> + return ret;
> + }
> +
> #ifdef CONFIG_EDAC_DEBUG
> if (edac_debug_level >= 3)
> edac_mc_dump_mci(mci);
> --
>
> right near the beginning of the function so that we can save us the
> unwinding.
>
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.
Tim Chen wrote:
> On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
> > Herbert,
> >
> > I've tried the module alias approach (see my earlier mail with patch)
> > but it didn't seem to load things properly. Can you check to see if
> > there's anything I did incorrectly.
> >
> > Tim
>
> I fixed a missing request_module statement in crct10dif library.
> So now things work if I have the following config:
>
> CONFIG_CRYPTO_CRCT10DIF=m
> CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> CONFIG_CRC_T10DIF=m
>
> However, when I have the library and generic algorithm compiled in,
> I do not see the PCLMULQDQ version loaded.
>
> CONFIG_CRYPTO_CRCT10DIF=y
> CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> CONFIG_CRC_T10DIF=y
>
> Perhaps I am initiating the crct10dif library at a really early
> stage when things are compiled in, where the module is not in
> initramfs? In that case, perhaps we should only allow
> PCLMUL version to be compiled in
> and not exist as a module?
I think that use of request_module("crct10dif") does not help loading
crct10dif-pclmul.ko when CONFIG_CRC_T10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m ,
for there is no / directory (note that the initramfs is not yet mounted as /
for loading modules which are not in vmlinux) when any module_init() functions
which are in vmlinux are called.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/72] 3.10.2-stable review
Please don't strip Cc's. This mailing list gets over 600 emails a day. Nobody bothers to read all emails. By stripping the Cc's your message will likely be ignored. Luckily for you, I filter for stable releases. On Fri, 2013-07-19 at 18:43 -0700, John wrote: > Two hunks fail for me patching source from linux-3.10.tar.xz as shown: > > patching file Documentation/parisc/registers > patching file Makefile > Hunk #1 FAILED at 1. > 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej You need to apply it against 3.10.1, not 3.10. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strange crashes in tcp_poll() via epoll_wait
Eric Dumazet wrote: > On Fri, 2013-07-19 at 23:50 +, Eric Wong wrote: > > Eric Dumazet wrote: > > > Hi Al > > > > > > I tried to debug strange crashes in tcp_poll() called from > > > sys_epoll_wait() -> sock_poll() > > > > > > The symptom is that sock->sk is NULL and we therefore dereference a NULL > > > pointer. > > > > > > It's really rare crashes but still, it would be nice to understand where > > > is the bug. Presumably latest kernels would crash in sock_poll() because > > > of the sk_can_busy_loop(sock->sk) call. > > > > > > We do test sock->sk being NULL in sock_fasync(), but epoll should be > > > safe because of existing synchronization (epmutex) ? > > > > It should be safe because of ep->mtx, actually, as epmutex is not taken > > in sys_epoll_wait. > > Hmm, it might be more complex than that for multi threaded programs : > > eventpoll_release_file() > > The problem might be because a thread closes a socket while an event > was queued for it. But ep->mtx is also held when traversing the ready list with ep_send_events_proc. Can sock->sk somehow be NULL before hitting eventpoll_release_file? > > I took a look at this but have not found anything. I've yet to see this > > this on my machines. > > > > When did you start noticing this? > > Hard to say, but we have these crashes on a 3.3+ based kernel. So I don't think any of my epoll changes caused it. Phew! > Probability of said crashes is very very low. This still worries me since I rely heavily on multi-threaded epoll. I don't have a lot of cores/CPUs, though, so maybe it's harder to trigger any potential race as a result... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mm: shift VM_GROWS* check from mmap_region() to do_mmap_pgoff()
On Tue, 16 Jul 2013, Andrew Morton wrote: > On Sun, 14 Jul 2013 18:54:51 +0200 Oleg Nesterov wrote: > > > mmap() doesn't allow the non-anonymous mappings with VM_GROWS* bit set. > > In particular this means that mmap_region()->vma_merge(file, vm_flags) > > must always fail if vm_flags & VM_GROWS. I didn't understand that sentence: if file is non-NULL perhaps? > > So it does not make sense to > > check VM_GROWS* after we already allocated the new vma, the only caller, > > do_mmap_pgoff(), which can pass this flag can do the check itself. > > > > And this looks a bit more correct, mmap_region() already unmapped the > > old mapping at this stage. But if mmap() is going to fail, it should > > avoid do_munmap() if possible. I agree with the sentiment, but the patch looks wrong to me. > > > > ... > > > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1327,6 +1327,9 @@ unsigned long do_mmap_pgoff(struct file *file, > > unsigned long addr, > > } > > } > > > > + /* Only MAP_PRIVATE|MAP_ANONYMOUS can use MAP_GROWS */ > > + if ((vm_flags & VM_MAYSHARE) && (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))) > > That is of course vm_flags&(VM_MAYSHARE|VM_GROWSDOWN|VM_GROWSUP), Seems very plausible, but I believe you're wrong on that! > but that perhaps is less clear. > > > + return -EINVAL; > > I had to stare for a while but yes, the change looks OK to me. It did need staring, yes, but it looks NOK to me: this change permits mmap(addr, len, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_GROWSDOWN, fd, off) where fd is for a real file: we never allowed MAP_GROWSDOWN on private (or shared) mappings of real files before, and I think we should not now. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/72] 3.10.2-stable review
Two hunks fail for me patching source from linux-3.10.tar.xz as shown:
patching file Documentation/parisc/registers
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file arch/arm/boot/dts/imx23.dtsi
patching file arch/arm/boot/dts/imx28.dtsi
patching file arch/arm/boot/dts/imx6dl.dtsi
patching file arch/arm/boot/dts/imx6q.dtsi
patching file arch/arm/include/asm/mmu_context.h
patching file arch/arm/kernel/perf_event.c
patching file arch/arm/kernel/smp_tlb.c
patching file arch/arm/kernel/smp_twd.c
patching file arch/arm/mach-shmobile/setup-emev2.c
patching file arch/arm/mach-shmobile/setup-r8a73a4.c
patching file arch/arm/mm/context.c
patching file arch/arm/mm/init.c
patching file arch/c6x/mm/init.c
patching file arch/parisc/include/asm/special_insns.h
patching file arch/parisc/include/asm/tlbflush.h
patching file arch/parisc/kernel/cache.c
patching file arch/parisc/lib/memcpy.c
patching file arch/x86/boot/compressed/eboot.c
patching file arch/x86/xen/time.c
patching file drivers/acpi/Makefile
patching file drivers/acpi/acpi_cmos_rtc.c
patching file drivers/acpi/acpica/hwxfsleep.c
patching file drivers/acpi/device_pm.c
patching file drivers/acpi/ec.c
patching file drivers/acpi/internal.h
patching file drivers/acpi/scan.c
patching file drivers/ata/ahci.c
patching file drivers/ata/libahci.c
patching file drivers/block/nbd.c
Hunk #3 succeeded at 745 (offset -1 lines).
patching file drivers/dma/pl330.c
patching file drivers/hid/hid-apple.c
patching file drivers/hid/hid-core.c
patching file drivers/hid/hid-ids.h
patching file drivers/hv/ring_buffer.c
patching file drivers/hv/vmbus_drv.c
patching file drivers/input/mouse/bcm5974.c
patching file drivers/net/wireless/iwlwifi/pcie/tx.c
patching file drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
patching file drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
patching file drivers/net/wireless/rtlwifi/rtl8723ae/sw.c
patching file drivers/parisc/lba_pci.c
patching file drivers/pci/iov.c
patching file drivers/pci/probe.c
patching file drivers/pci/quirks.c
patching file drivers/pci/xen-pcifront.c
patching file drivers/pcmcia/at91_cf.c
patching file drivers/rtc/rtc-rv3029c2.c
patching file drivers/tty/serial/pch_uart.c
patching file drivers/usb/gadget/f_mass_storage.c
patching file drivers/usb/host/ehci-omap.c
patching file drivers/usb/host/xhci-mem.c
patching file drivers/usb/host/xhci-plat.c
patching file drivers/usb/serial/option.c
patching file drivers/usb/serial/qcserial.c
patching file fs/btrfs/ctree.c
patching file fs/btrfs/send.c
patching file fs/cifs/cifs_unicode.h
patching file fs/cifs/cifsencrypt.c
patching file fs/cifs/file.c
patching file fs/cifs/inode.c
patching file fs/ext3/namei.c
patching file fs/ext4/balloc.c
patching file fs/ext4/extents.c
patching file fs/ext4/file.c
patching file fs/ext4/inline.c
patching file fs/ext4/inode.c
patching file fs/ext4/mballoc.c
patching file fs/ext4/namei.c
patching file fs/ext4/resize.c
patching file fs/ext4/super.c
patching file fs/jbd2/journal.c
patching file fs/jbd2/transaction.c
patching file fs/ocfs2/xattr.c
patching file fs/ubifs/super.c
patching file include/linux/cgroup.h
patching file include/linux/nbd.h
patching file kernel/cgroup.c
patching file kernel/irq/manage.c
patching file kernel/timer.c
patching file mm/memcontrol.c
Hunk #1 FAILED at 6296.
1 out of 1 hunk FAILED -- saving rejects to file mm/memcontrol.c.rej
patching file mm/page_alloc.c
patching file mm/slab.c--- Makefile
+++ Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 1
-EXTRAVERSION =
+SUBLEVEL = 2
+EXTRAVERSION = -rc2
NAME = Unicycling Gorilla
# *DOCUMENTATION*
--- mm/memcontrol.c
+++ mm/memcontrol.c
@@ -6296,14 +6296,6 @@
error = memcg_init_kmem(memcg, _cgroup_subsys);
mutex_unlock(_create_mutex);
- if (error) {
- /*
- * We call put now because our (and parent's) refcnts
- * are already in place. mem_cgroup_put() will internally
- * call __mem_cgroup_free, so return directly
- */
- mem_cgroup_put(memcg);
- }
return error;
}
Re: [PATCH -tip 0/3] kprobes, x86: Move optprobe on top of int3-based instruction patching
On Thu, 2013-07-18 at 20:47 +0900, Masami Hiramatsu wrote: > Hi, > > Here is a series of kprobes and x86 patches for moving > optprobe (jump optimized kprobe) onto the int3-based > instruction patching (a.k.a. text_poke_bp, introduced by > Jiri Kosina). > > Since this completely moves text_poke_smp* user to new > text_poke_bp, I also remove the old text_poke_smp* code > from alternative.c. As a side effect, it also fixes a > Kconfig warning about CONFIG_STOP_MACHINE dependency > confliction. > > Thank you, > > --- > > Masami Hiramatsu (3): > [CLEANUP] kprobes/x86: Remove an incorrect comment about int3 in NMI/MCE > kprobes/x86: Use text_poke_bp() instead of text_poke_smp*() > x86: Remove unused text_poke_smp and text_poke_smp_batch Nice work Masami! Reviewed-by: Steven Rostedt -- Steve > > > arch/x86/Kconfig |5 -- > arch/x86/include/asm/alternative.h | 11 > arch/x86/kernel/alternative.c | 98 +--- > arch/x86/kernel/kprobes/common.h |5 -- > arch/x86/kernel/kprobes/core.c |2 - > arch/x86/kernel/kprobes/opt.c | 110 > +++- > 6 files changed, 25 insertions(+), 206 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.11-rc1 regression] ext4_evict_inode triggers warn_slowpath_common on sparc64
On Fri, Jul 19, 2013 at 07:29:25PM +0200, Mikael Pettersson wrote: > I keep getting the following warning with 3.11-rc1 on sparc64: > > [ cut here ] > WARNING: CPU: 1 PID: 8174 at fs/ext4/inode.c:230 > ext4_evict_inode+0x1f0/0x448() > Modules linked in: sunrpc af_packet ipv6 hid_generic snd_ali5451 > snd_ac97_codec snd_seq snd_seq_device snd_pcm tg3 snd_timer flash ohci_pci > hwmon snd soundcore ptp evdev sg i2c_ali1535 ohci_hcd pps_core snd_page_alloc > i2c_core ac97_bus sr_mod cdrom pata_ali libata > CPU: 1 PID: 8174 Comm: xgcc Not tainted 3.11.0-rc1 #1 > Call Trace: > [004537b0] warn_slowpath_common+0x4c/0x64 > [00540d78] ext4_evict_inode+0x1f0/0x448 > [004f3938] evict+0xb8/0x190 > [004e99bc] do_unlinkat+0xf4/0x160 > [00406174] linux_sparc_syscall32+0x34/0x40 > ---[ end trace cd72b9e3e68d89e4 ]--- > > The Comm varies, but the call trace always looks like that. Happens a couple > of times per day, so far. No other ill effects observed. Didn't happen in > 3.10 > or older kernels. The fix, commit 822dbba33458cd6ad is already in Linus's tree, and will be included in -rc2. Note that this can cause memory corruption caused by a use-after-free. I've not noticed a problem in my personal testing, but it's been reported to me that with stress testing (using memory cgroups amonng other things) and the system wedged when the machine was rebooted after the tests were completed, and it only came back after the watchdog timer fired. The fix up was one of the first things which Linus pulled after releasing -rc1, so you can merge 47188d39b5de to get the fixes. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
> On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
> > On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
> > >
> > > The issue here seems to be the dynamic binding nature of the crypto
> > > subsystem. When something needs crypto, it will request the appropriate
> > > crypto module (e.g. crct10dif), which may race with detecting a specific
> > > hardware accelerator based on CPUID or device information (e.g.
> > > crct10dif_pclmul).
> > >
> > > RAID has effectively the same issue, and we just "solved" it by
> > > compiling in all the accelerators into the top-level module.
> >
> > I think for crypto the simplest solution is to not do CPUID-based
> > loading. Then crypto users will simply load the module alias which
> > causes modprobe to load all modules providing that alias.
> >
> > Cheers,
>
> Herbert,
>
> I've tried the module alias approach (see my earlier mail with patch)
> but it didn't seem to load things properly. Can you check to see if
> there's anything I did incorrectly.
>
> Tim
I fixed a missing request_module statement in crct10dif library.
So now things work if I have the following config:
CONFIG_CRYPTO_CRCT10DIF=m
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_T10DIF=m
However, when I have the library and generic algorithm compiled in,
I do not see the PCLMULQDQ version loaded.
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_T10DIF=y
Perhaps I am initiating the crct10dif library at a really early
stage when things are compiled in, where the module is not in
initramfs? In that case, perhaps we should only allow
PCLMUL version to be compiled in
and not exist as a module?
Here's the patch I tried:
Signed-off-by: Tim Chen
---
arch/x86/crypto/crct10dif-pclmul_glue.c | 8 +---
crypto/Makefile | 2 +-
crypto/{crct10dif.c => crct10dif_generic.c} | 1 +
lib/crc-t10dif.c| 1 +
4 files changed, 4 insertions(+), 8 deletions(-)
rename crypto/{crct10dif.c => crct10dif_generic.c} (99%)
diff --git a/arch/x86/crypto/crct10dif-pclmul_glue.c
b/arch/x86/crypto/crct10dif-pclmul_glue.c
index 7845d7f..7ad5f09 100644
--- a/arch/x86/crypto/crct10dif-pclmul_glue.c
+++ b/arch/x86/crypto/crct10dif-pclmul_glue.c
@@ -121,15 +121,9 @@ static struct shash_alg alg = {
}
};
-static const struct x86_cpu_id crct10dif_cpu_id[] = {
- X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
- {}
-};
-MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
-
static int __init crct10dif_intel_mod_init(void)
{
- if (!x86_match_cpu(crct10dif_cpu_id))
+ if (!cpu_has_pclmulqdq)
return -ENODEV;
return crypto_register_shash();
diff --git a/crypto/Makefile b/crypto/Makefile
index 2d5ed08..3fd76fa 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -83,7 +83,7 @@ obj-$(CONFIG_CRYPTO_ZLIB) += zlib.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
-obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif_generic.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_LZ4) += lz4.o
diff --git a/crypto/crct10dif.c b/crypto/crct10dif_generic.c
similarity index 99%
rename from crypto/crct10dif.c
rename to crypto/crct10dif_generic.c
index 92aca96..c960a95 100644
--- a/crypto/crct10dif.c
+++ b/crypto/crct10dif_generic.c
@@ -176,3 +176,4 @@ module_exit(crct10dif_mod_fini);
MODULE_AUTHOR("Tim Chen ");
MODULE_DESCRIPTION("T10 DIF CRC calculation.");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("crct10dif");
diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c
index fe3428c..d8cd353 100644
--- a/lib/crc-t10dif.c
+++ b/lib/crc-t10dif.c
@@ -38,6 +38,7 @@ EXPORT_SYMBOL(crc_t10dif);
static int __init crc_t10dif_mod_init(void)
{
+ request_module("crct10dif");
crct10dif_tfm = crypto_alloc_shash("crct10dif", 0, 0);
return PTR_RET(crct10dif_tfm);
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New device tree mailing list
On Fri, 2013-07-19 at 18:23 -0700, Grant Likely wrote: > The ozlabs devicetree list was requiring too much work to moderate, so > I'm closing down that list and replacing it with a list on > vger.kernel.org. > > http://vger.kernel.org/vger-lists.html#devicetree Hey Grant. Can you also please setup an email archive? Something like gmane or equivalent. Maybe a patchwork entry too? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, tboot: iomem fixes
Current code doesn't use specific interface to access I/O space.
So some potential bugs can be caused. We can fix this by using
specific API.
Signed-off-by: Qiaowei Ren
---
arch/x86/kernel/tboot.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 3ff42d2..c902237 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -466,9 +466,12 @@ struct sinit_mle_data {
u32 vtd_dmars_off;
} __packed;
+#define SINIT_MLE_DATA_VTD_DMAR_OFF140
+
struct acpi_table_header *tboot_get_dmar_table(struct acpi_table_header
*dmar_tbl)
{
- void *heap_base, *heap_ptr, *config;
+ void __iomem *heap_base, *heap_ptr, *config;
+ u32 dmar_tbl_off;
if (!tboot_enabled())
return dmar_tbl;
@@ -485,25 +488,25 @@ struct acpi_table_header *tboot_get_dmar_table(struct
acpi_table_header *dmar_tb
return NULL;
/* now map TXT heap */
- heap_base = ioremap(*(u64 *)(config + TXTCR_HEAP_BASE),
- *(u64 *)(config + TXTCR_HEAP_SIZE));
+ heap_base = ioremap(readl(config + TXTCR_HEAP_BASE),
+ readl(config + TXTCR_HEAP_SIZE));
iounmap(config);
if (!heap_base)
return NULL;
/* walk heap to SinitMleData */
/* skip BiosData */
- heap_ptr = heap_base + *(u64 *)heap_base;
+ heap_ptr = heap_base + readq(heap_base);
/* skip OsMleData */
- heap_ptr += *(u64 *)heap_ptr;
+ heap_ptr += readq(heap_ptr);
/* skip OsSinitData */
- heap_ptr += *(u64 *)heap_ptr;
+ heap_ptr += readq(heap_ptr);
/* now points to SinitMleDataSize; set to SinitMleData */
heap_ptr += sizeof(u64);
/* get addr of DMAR table */
+ dmar_tbl_off = readl(heap_ptr + SINIT_MLE_DATA_VTD_DMAR_OFF);
dmar_tbl = (struct acpi_table_header *)(heap_ptr +
- ((struct sinit_mle_data *)heap_ptr)->vtd_dmars_off -
- sizeof(u64));
+ dmar_tbl_off - sizeof(u64));
/* don't unmap heap because dmar.c needs access to this */
--
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/
New device tree mailing list
Hello everyone, The ozlabs devicetree list was requiring too much work to moderate, so I'm closing down that list and replacing it with a list on vger.kernel.org. http://vger.kernel.org/vger-lists.html#devicetree I'll be sending a patch to MAINTAINERS shortly. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs fixes for -rc2
sget() one is a long-standing bug and will need to go into -stable (in fact, it had been originally caught in RHEL6), the other two are 3.11-only. Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (2): allow O_TMPFILE to work with O_WRONLY livelock avoidance in sget() Peng Tao (1): vfs: constify dentry parameter in d_count() Diffstat: fs/open.c|2 ++ fs/super.c | 25 ++--- include/linux/dcache.h |2 +- include/uapi/asm-generic/fcntl.h |4 ++-- 4 files changed, 15 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sysctl net: Keep tcp_syn_retries inside the boundary
From: Michal Tesar Date: Fri, 19 Jul 2013 14:09:01 +0200 > Limit the min/max value passed to the > /proc/sys/net/ipv4/tcp_syn_retries. > > Signed-off-by: Michal Tesar Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mISDN: replace sum of bitmasks with OR operation.
From: Alexandru Juncu Date: Thu, 18 Jul 2013 14:36:48 +0300 > Suggested by coccinelle and manually verified. > > Signed-off-by: Alexandru Juncu 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 1/1] net/velocity: add poll controller function for velocity nic
From: Amit Uttamchandani Date: Thu, 18 Jul 2013 17:45:22 -0700 > Add poll controller function for velocity nic. > > Signed-off-by: Amit Uttamchandani 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/irda: fixed style issues in irttp
From: Dragos Foianu Date: Wed, 17 Jul 2013 12:25:38 +0100 > Applied error fixes suggested by checpatch.pl > > Signed-off-by: Dragos Foianu 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: [ 00/72] 3.10.2-stable review
On Fri, Jul 19, 2013 at 11:16:47PM +, Shuah Khan wrote: > On 07/19/2013 09:32 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.2 release. > > There are 72 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Jul 21 05:25:08 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Patches applied cleanly to 3.0.86, 3.4.54, 3.9.10, and 3.10.1 > > 3.9.11-rc1 patch failed to build: > x64-64, mipsel, mips, powerpc, and tile: build failed with the following > error: Thanks for testing and sending the results. I've fixed the 3.9 build issue and will push a new patch out in a bit. 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: mlockall triggred rcu_preempt stall.
On Fri, Jul 19, 2013 at 03:15:39PM -0700, Paul E. McKenney wrote: > On Fri, Jul 19, 2013 at 10:53:23AM -0400, Dave Jones wrote: > > My fuzz tester keeps hitting this. Every instance shows the non-irq stack > > came in from mlockall. I'm only seeing this on one box, but that has more > > ram (8gb) than my other machines, which might explain it. > > Are you building CONFIG_PREEMPT=n? I don't see any preemption points in > do_mlockall(), so a range containing enough vmas might well stall the > CPU in that case. That was with full preempt. > Does the patch below help? If so, we probably need others, but let's > first see if this one helps. ;-) I'll try it on Monday. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] more ext4 bug fixes
The following changes since commit e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1: ext4: don't allow ext4_free_blocks() to fail due to ENOMEM (2013-07-13 00:40:35 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to 63b999685cb372e24eb73f255cd73547026370fd: ext4: call ext4_es_lru_add() after handling cache miss (2013-07-16 10:28:47 -0400) Fixes for 3.11-rc2, sent at 5pm, in the professoinal style. :-) Theodore Ts'o (5): ext4: fix error handling in ext4_ext_truncate() ext4: simplify calculation of blocks to free on error ext4: make the extent_status code more robust against ENOMEM failures ext4: yield during large unlinks ext4: call ext4_es_lru_add() after handling cache miss fs/ext4/extents.c| 23 +++ fs/ext4/extents_status.c | 51 +++ fs/ext4/inode.c | 7 ++- 3 files changed, 60 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strange crashes in tcp_poll() via epoll_wait
On Fri, 2013-07-19 at 23:50 +, Eric Wong wrote: > Eric Dumazet wrote: > > Hi Al > > > > I tried to debug strange crashes in tcp_poll() called from > > sys_epoll_wait() -> sock_poll() > > > > The symptom is that sock->sk is NULL and we therefore dereference a NULL > > pointer. > > > > It's really rare crashes but still, it would be nice to understand where > > is the bug. Presumably latest kernels would crash in sock_poll() because > > of the sk_can_busy_loop(sock->sk) call. > > > > We do test sock->sk being NULL in sock_fasync(), but epoll should be > > safe because of existing synchronization (epmutex) ? > > It should be safe because of ep->mtx, actually, as epmutex is not taken > in sys_epoll_wait. Hmm, it might be more complex than that for multi threaded programs : eventpoll_release_file() The problem might be because a thread closes a socket while an event was queued for it. > > I took a look at this but have not found anything. I've yet to see this > this on my machines. > > When did you start noticing this? Hard to say, but we have these crashes on a 3.3+ based kernel. Probability of said crashes is very very low. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: pfuze100: add pfuze100 regulator driver
Thanks Mark, I will send V4. -Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Saturday, July 20, 2013 1:31 AM To: Gong Yibin-B38343 Cc: grant.lik...@linaro.org; rob.herr...@calxeda.com; r...@landley.net; lgirdw...@gmail.com; shawn@linaro.org; devicetree-disc...@lists.ozlabs.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] regulator: pfuze100: add pfuze100 regulator driver On Fri, Jul 19, 2013 at 06:14:51PM +0800, Robin Gong wrote: > Add pfuze100 regulator driver. Looks good, there's some minor issues below but they should be small. > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -158,6 +158,13 @@ config REGULATOR_MC13892 > Say y here to support the regulators found on the Freescale MC13892 > PMIC. > > +config REGULATOR_PFUZE100 > + tristate "Support regulators on Freescale PFUZE100 PMIC" > + depends on I2C > + help > + Say y here to support the regulators found on the Freescale PFUZE100 > + PMIC. > + Please keep this and the Makefile sorted - if there's issues merging then please use my topic/kconfig as a base. > + if (val & 0x40) > + ramp_delay = 5 / (4 * ramp_delay); > + else > + ramp_delay = 25000 / (2 * ramp_delay); > + if (id <= PFUZE100_SW1C) > + ramp_delay = 25000 / (2 * ramp_delay); This is a bit confusing as there's a cumalaitve modification applied to ramp_delay in the case that id is less than SW1C but it's not obvious that this is intentional given the calculations. Please change this to make it clearer what the intended logic is (assuming it's not buggy) - something like if ... else if ... else for example. > + ret = regmap_read(pfuze_chip->regmap, PFUZE100_REVID, ); > + if (ret) > + return ret; > + dev_info(pfuze_chip->dev, > + "Full lay: %x ,Metal lay: %x\n", > + (value & 0xf0) >> 4, value & 0x0f); The space should be after not before the comma in the displayed string. > + dev_info(pfuze_chip->dev, "FAB: %x , FIN: %x\n", > + (value & 0xc) >> 2, value & 0x3); Only a space after the , for normal formatting. ie both should look like "%x, bar". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/72] 3.10.2-stable review
Hi On Friday 19 July 2013, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.2 release. […] > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc1.gz > and the diffstat can be found below. Minor nit, this introduces trailing whitespace in "SUBLEVEL = 2 ". […] diff --git a/Makefile b/Makefile index b75cc30..9b47ed3 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 3 PATCHLEVEL = 10 -SUBLEVEL = 1 -EXTRAVERSION = +SUBLEVEL = 2 +EXTRAVERSION = -rc1 NAME = Unicycling Gorilla # *DOCUMENTATION* […] 3.9.11-rc1, 3.4.54-rc1 and 3.0.87-rc1 are not affected. Thank you a lot for your efforts of -stable maintenance! Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/38] 3.9.11-stable review
On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote: > On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote: >> On Fri, Jul 19, 2013 at 04:45:25PM +, Shuah Khan wrote: >>> On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote: --- Note, this is the LAST 3.9-stable kernel release that I will be doing. Please move to the 3.10-stable branch as soon as possible. --- This is the start of the stable review cycle for the 3.9.11 release. There are 38 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Jul 21 05:20:01 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz and the diffstat can be found below. thanks, greg k-h >>> >>> Greg, >>> >>> Build failed with the following error: >>> >>> LD ipc/built-in.o >>> CC [M] fs/cifs/inode.o >>> fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’: >>> fs/cifs/inode.c:560:4: error: implicit declaration of function >>> ‘cifs_dbg’ [-Werror=implicit-function-declaration] >>> cc1: some warnings being treated as errors >>> make[2]: *** [fs/cifs/inode.o] Error 1 >>> make[1]: *** [fs/cifs] Error 2 >>> make: *** [fs] Error 2 >>> make: *** Waiting for unfinished jobs >>> CC security/selinux/hooks.o >>> >>> I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled. >>> cifs_dbg() is not defined. >> >> Ugh, I thought I fixed that one... I did it for the 3.4 and other >> trees, I'll go see what I did wrong... > > Ok, I've now fixed this, I don't know how it got through my tests, when > I tried it again, it failed. Before it wasn't, odd... > > Anyway, there is a new -rc2 kernel patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz > > If you could test that out, I would appreciate it, to ensure I didn't do > anything stupid with this one too. > > Ick, handling 4 kernels at once really takes its toll on me, this was > not a good review cycle... > > thanks, > > greg k-h > Greg, rc2 compiled on x86-64. I will run cross-compile tests and boot tests later on today or tomorrow morning and report the results. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[please disregard] Re: [ 00/72] 3.10.2-stable review
Hi On Saturday 20 July 2013, Stefan Lippers-Hollmann wrote: […] > Minor nit, this introduces trailing whitespace in "SUBLEVEL = 2 ". Please apologize for the noise, my mail client somehow hid the previous sub thread pointing this out already. Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/18] 3.0.87-stable review
On 07/19/2013 05:52 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.87 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 21 02:10:01 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.87-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.86, 3.4.54, 3.9.10, and 3.10.1 3.9.11-rc1 patch failed to build: x64-64, mipsel, mips, powerpc, and tile: build failed with the following error: LD ipc/built-in.o CC [M] fs/cifs/inode.o fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’: fs/cifs/inode.c:560:4: error: implicit declaration of function ‘cifs_dbg’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [fs/cifs/inode.o] Error 1 make[1]: *** [fs/cifs] Error 2 make: *** [fs] Error 2 make: *** Waiting for unfinished jobs CC security/selinux/hooks.o I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled. cifs_dbg() is not defined. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.54-rc1, 3.9.10-rc1, 3.10.2-rc2) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y, and 3.10.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.9.y, and 3.10.y mips: defconfig passed on all, except 3.9.10 mipsel: defconfig passed on all, except 3.9.10 powerpc: wii_defconfig passed on all, except 3.9.10 sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all, except 3.9.10 -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator
On Wed, Jul 17, 2013 at 2:30 AM, Robin Holt wrote: > On Wed, Jul 17, 2013 at 01:17:44PM +0800, Sam Ben wrote: >> >With this patch, we did boot a 16TiB machine. Without the patches, >> >the v3.10 kernel with the same configuration took 407 seconds for >> >free_all_bootmem. With the patches and operating on 2MiB pages instead >> >of 1GiB, it took 26 seconds so performance was improved. I have no feel >> >for how the 1GiB chunk size will perform. >> >> How to test how much time spend on free_all_bootmem? > > We had put a pr_emerg at the beginning and end of free_all_bootmem and > then used a modified version of script which record the time in uSecs > at the beginning of each line of output. used two patches, found 3TiB system will take 100s before slub is ready. about three portions: 1. sparse vmemap buf allocation, it is with bootmem wrapper, so clear those struct page area take about 30s. 2. memmap_init_zone: take about 25s 3. mem_init/free_all_bootmem about 30s. so still wonder why 16TiB will need hours. also your patches looks like only address 2 and 3. Yinghai printk_time_tsc_0.patch Description: Binary data printk_time_tsc_1.patch Description: Binary data
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote: > On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote: > > Alas, this is not the one I'd like to apply. > > > > With that patch applied, new device objects are created to avoid binding the > > processor driver directly to the cpu system device objects, because that > > apparently confuses udev and it starts to ignore the cpu modalias once the > > driver has been bound to any of those objects. > > > > I've verified in the meantime that this indeed is the case. > > > > A link to the patch in question: https://patchwork.kernel.org/patch/2830561/ > > > > Greg, I asked you some time ago whether or not it was possible for udev to > > stop > > autoloading modules that matched the cpu modalias after a driver had been > > bound > > to the cpu system device objects and you said "no". However, this time I > > can > > say with certainty that that really is the case. So, the question now is > > whether or not we can do anything in the kernel to avoid that confusion in > > udev > > instead of applying the patch linked above (which is beyond ugly in my not > > so > > humble opinion)? > > udev isn't doing any module loading, 'modprobe' is just being called for > any new module alias that shows up in the system, and all of the drivers > that match it then get loaded. The problem is that that doesn't happen when a driver is bound to the cpu system device objects. modprobe is just not called for modules that match the cpu modalias in that case. If I call modprobe manually for any of the modules in question, it loads and works no problem. > How is it a problem if a module is attempted to be loaded that is > already loaded? How is it a problem if a different module is loaded for > a device already bound to a driver? Both of those should be total > "no-ops" for the kernel. Precisely, but that's not what happens in practice, hence my question. The situation is this: - With 3.11-rc1 modules that match the CPU modalias are not loaded automatically (that is, modprobe is not called for them by udev) after the processor module is loaded. - With 3.10 they are loaded automatically at any time. - With the patch at https://patchwork.kernel.org/patch/2830561/ on top of 3.11-rc1 the situation is the same as for 3.10. Therefore we have a kernel regression from 3.10 (with respect to the existing user space which is udev) in 3.11-rc1 3.10 and the patch at https://patchwork.kernel.org/patch/2830561/ makes that regression go away. However, that patch is totally voodoo programming, so I wonder if there is any saner alternative or we really need to do voodoo programming in the kernel to work around udev's confusion. > But, I don't know anything about the cpu code, how is loading a module > causing problems? That sounds like it needs to be fixes, as any root > user can load modules whenever they want, you can't protect the kernel > from doing that. Yes, that needs to be fixed, but I don't know *why* it is a problem in the first place. I'd like to understand what's going on, because I don't right now. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
On Fri, Jul 19, 2013 at 11:42:11AM +0200, Maxime Ripard wrote: > On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote: > > On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote: > > > On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote: > > > > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote: > > > > > So using these new patches for binary attributes, how can I pass data > > > > > between my driver and the sysfs files using a platform_driver? Or are > > > > > other 'hacks' needed and using the .groups attribute from > > > > > platform_driver->device_driver->groups is really the wrong approach. > > > > > > > > > > I did ask around and still haven't figured it out so far, so I do > > > > > apologize if you feel I'm wasting your precious time. > > > > > > > > How is the platform device not the same thing that was passed to your > > > > probe function? > > > > > > One thing I don't get here is why it should be set in the > > > platform_driver structure. From my understanding of the device model, > > > and since what Oliver is trying to do is exposing a few bytes of memory > > > to sysfs, shouldn't the sysfs file be attached to the device instead? > > > > It will be created by the driver core for any device attached to the > > driver automatically. > > > > > I mean, here, the sysfs file will be created under something like > > > .../drivers/sunxi-sid/eeprom. What happens when you have several > > > instances of that driver loaded? I'd expect it to have several sysfs > > > files created, one for each instance. So to me, it should be in the > > > device structure, not the driver one. > > > > You can't have multiple drivers with the same name loaded (or the same > > module loaded multiple times.) You can have multiple devices for a > > single driver, which is what we do all the time. > > Yes, I know that, and it's actually my point. > With the current oliver's code he pasted earlier in this thread: > > # find /sys/ -name eeprom > /sys/bus/platform/drivers/sunxi-sid/eeprom > > While I'd expect the eeprom file to be located in > /sys/bus/platform/devices/X.eeprom/eeprom like it used to be in the v4, > since it's an instance-specific content. Oh crap. You are totally right. That's why we added the new device create call, to allow this to work properly. Right now you are getting the kobject of the driver, not the device, in the callback, which is not what you want (sure, if you only have once instance, you can work around it, but don't it's the driver core's fault for not giving you the correct api...) Let me go look at how I can make this work "easier", give me a few days. 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: [ 00/38] 3.9.11-stable review
On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote: > On Fri, Jul 19, 2013 at 04:45:25PM +, Shuah Khan wrote: > > On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote: > > > --- > > > Note, this is the LAST 3.9-stable kernel release that I will be doing. > > > Please move to the 3.10-stable branch as soon as possible. > > > --- > > > > > > This is the start of the stable review cycle for the 3.9.11 release. > > > There are 38 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Jul 21 05:20:01 UTC 2013. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > > > > Greg, > > > > Build failed with the following error: > > > >LD ipc/built-in.o > >CC [M] fs/cifs/inode.o > > fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’: > > fs/cifs/inode.c:560:4: error: implicit declaration of function > > ‘cifs_dbg’ [-Werror=implicit-function-declaration] > > cc1: some warnings being treated as errors > > make[2]: *** [fs/cifs/inode.o] Error 1 > > make[1]: *** [fs/cifs] Error 2 > > make: *** [fs] Error 2 > > make: *** Waiting for unfinished jobs > >CC security/selinux/hooks.o > > > > I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled. > > cifs_dbg() is not defined. > > Ugh, I thought I fixed that one... I did it for the 3.4 and other > trees, I'll go see what I did wrong... Ok, I've now fixed this, I don't know how it got through my tests, when I tried it again, it failed. Before it wasn't, odd... Anyway, there is a new -rc2 kernel patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz If you could test that out, I would appreciate it, to ensure I didn't do anything stupid with this one too. Ick, handling 4 kernels at once really takes its toll on me, this was not a good review cycle... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strange crashes in tcp_poll() via epoll_wait
Eric Dumazet wrote: > Hi Al > > I tried to debug strange crashes in tcp_poll() called from > sys_epoll_wait() -> sock_poll() > > The symptom is that sock->sk is NULL and we therefore dereference a NULL > pointer. > > It's really rare crashes but still, it would be nice to understand where > is the bug. Presumably latest kernels would crash in sock_poll() because > of the sk_can_busy_loop(sock->sk) call. > > We do test sock->sk being NULL in sock_fasync(), but epoll should be > safe because of existing synchronization (epmutex) ? It should be safe because of ep->mtx, actually, as epmutex is not taken in sys_epoll_wait. I took a look at this but have not found anything. I've yet to see this this on my machines. When did you start noticing this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 19 July 2013 11:59 AM, Greg KH wrote: > > On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: > >> Hi, > >> > >> On Friday 19 July 2013 11:13 AM, Greg KH wrote: > >>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: > +ret = dev_set_name(>dev, "%s.%d", dev_name(dev), id); > >>> > >>> Your naming is odd, no "phy" anywhere in it? You rely on the sender > >>> to > >>> never send a duplicate name.id pair? Why not create your own ids > >>> based > >>> on the number of phys in the system, like almost all other classes and > >>> subsystems do? > >> > >> hmm.. some PHY drivers use the id they provide to perform some of their > >> internal operation as in [1] (This is used only if a single PHY > >> provider > >> implements multiple PHYS). Probably I'll add an option like > >> PLATFORM_DEVID_AUTO > >> to give the PHY drivers an option to use auto id. > >> > >> [1] -> > >> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html > > > > No, who cares about the id? No one outside of the phy core ever should, > > because you pass back the only pointer that they really do care about, > > if they need to do anything with the device. Use that, and then you can > > hmm.. ok. > > > rip out all of the "search for a phy by a string" logic, as that's not > > Actually this is needed for non-dt boot case. In the case of dt boot, we > use a > phandle by which the controller can get a reference to the phy. But in > the case > of non-dt boot, the controller can get a reference to the phy only by > label. > >>> > >>> I don't understand. They registered the phy, and got back a pointer to > >>> it. Why can't they save it in their local structure to use it again > >>> later if needed? They should never have to "ask" for the device, as the > >> > >> One is a *PHY provider* driver which is a driver for some PHY device. This > >> will > >> use phy_create to create the phy. > >> The other is a *PHY consumer* driver which might be any controller driver > >> (can > >> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to > >> the > >> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt > >> boot). > >>> device id might be unknown if there are multiple devices in the system. > >> > >> I agree with you on the device id part. That need not be known to the PHY > >> driver. > > > > How does a consumer know which "label" to use in a non-dt system if > > there are multiple PHYs in the system? > > That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a "name". thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for May 2 (platform/x86/samsung-laptop)
On Fri, Jul 19, 2013 at 10:19:14AM -0700, Randy Dunlap wrote: > On 05/02/13 14:26, Randy Dunlap wrote: > > On 05/02/13 00:35, Stephen Rothwell wrote: > >> Hi all, > >> > >> Please do not add any v3.11 destined work to your linux-next included > >> branches until after v3.10-rc1 is released. > >> > >> Changes since 20130501: > >> > > > > > > when CONFIG_ACPI_VIDEO=m and CONFIG_SAMSUNG_LAPTOP=y: > > > > drivers/built-in.o: In function `samsung_init': > > samsung-laptop.c:(.init.text+0x94ba): undefined reference to > > `acpi_video_unregister' > > > > > > > > This build error still happens in linux-next of 20130719... I have not been the samsung-laptop driver maintainer for a few years now, so there's nothing I can do about this, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] relay: fix timer madness
On Wed, Jul 10, 2013 at 10:18:54AM +0800, zhangwei(Jovi) wrote:
> @@ -339,6 +339,10 @@ static void wakeup_readers(unsigned long data)
> {
> struct rchan_buf *buf = (struct rchan_buf *)data;
> wake_up_interruptible(>read_wait);
> + /*
> + * Stupid polling for now:
> + */
> + mod_timer(>timer, HZ / 10);
mod_timer() takes an offset so probably "jiffies + HZ / 10" was
intended here and also below. Certainly passing "HZ / 10" doesn't
make any kind of sense.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Fri, 19 Jul 2013 16:43:53 -0400 Steven Rostedt wrote: > On Fri, 2013-07-19 at 13:33 -0700, James Bottomley wrote: > > > If you're basing your entire theory on male/female interaction on > > teenagers, then I'm afraid your wife might be on to something ... > > No, it's also based on interaction with my Wife and her sister too ;-) > I genuinely think the gender difference is a distraction. The simple fact is that people are different. Wildly amazingly beautifully different. Certainly some metrics have starkly different averages for men than women, and there can be biological and social drivers of that. But those metrics very often vary greatly among men and among women. But it's really people that are different. Some people are very perceptive of, and responsive to, those differences. They are able and willing to listen and understand and adjust. They try to fit in with others. I know a few people like that and I am staggered by how effectively they bond with other people. Other people are blind to the differences. They expect everyone to be just like themselves. When the reality shows that isn't true they create coarse stereotypes to allow them to pigeon hole others. This naturally leads to prejudice and sometimes to hate. And I know a few people like that too - maybe not quite the extreme, but certainly closer to that extreme than me. I believe that the abstract/mathematical/literal abilities that allow someone to be good at software development is inversely correlated with the holistic/forgiving/flexible abilities that allow someone to be good at understanding others. One needs to care deeply about small details. The other needs to work with hints and suggestions and accept that precision is simply not available. I know for myself that such understanding of people as I have has developed slowly due to hard work, patience from a loving wife and others, and from me stepping well outside my comfort zone - where as the mathematical ability was obvious in kindergarten and never needed any encouragement. And the people I know who are very good with other people are about as comfortable with technology as I am with strangers (i.e. not very). If this negative correlation is true, then it says something very important about our community. I don't think there is any need for me to spell it out. I think the recent discussion demonstrates this quite clearly. Lots of beating on chests, very little meeting of minds. Lots of talk about technical solutions (or non-solutions), very little suggestion of acknowledgement, accommodation or compromise. [some - yes. But not much] Maybe that is just who we are. Yes, we are sometimes blind to differences in others and can lead us to hurt and repel them. But that blindness allows us to focus on excellence in technology and so it is worth it. Or maybe that is only who were were. Maybe we've got the technology pretty much under control and we (individuals) can choose to put more effort into listening to people who are very different to us. Stop accepting the fact that we "just don't understand some people" and use our not inconsiderable intellect find some understanding. (and no, I don't completely understand my wife either, but I'm sure I understand her better now than I once did). NeilBrown signature.asc Description: PGP signature
Re: 3.10.0 i386 uniprocessor panic
> A disassembly of the calling function, i.e.: > > [] ? run_timer_softirq+0x150/0x165 > > ... would be a good idea, at least. Here you go. Note that the machine isn't doing anything of interest, so after a quick search for residual personal data I could give you a root login on it. (Just send ssh key.) kernel/timer.o: file format elf32-i386 Disassembly of section .text: [snip...] 0289 : 289: 55 push %ebp 28a: 57 push %edi 28b: 56 push %esi 28c: 53 push %ebx 28d: 83 ec 24sub$0x24,%esp 290: 8b 1d 00 00 00 00 mov0x0,%ebx 296: e8 fc ff ff ff call 297 29b: a1 00 00 00 00 mov0x0,%eax 2a0: 3b 43 04cmp0x4(%ebx),%eax 2a3: 0f 88 3d 01 00 00 js 3e6 2a9: fa cli 2aa: 8d 83 10 08 00 00 lea0x810(%ebx),%eax 2b0: 89 44 24 14 mov%eax,0x14(%esp) 2b4: 8d 83 10 0a 00 00 lea0xa10(%ebx),%eax 2ba: 89 44 24 18 mov%eax,0x18(%esp) 2be: a1 00 00 00 00 mov0x0,%eax 2c3: 8b 4b 04mov0x4(%ebx),%ecx 2c6: 39 c8 cmp%ecx,%eax 2c8: 0f 88 11 01 00 00 js 3df 2ce: 0f b6 f1movzbl %cl,%esi 2d1: 85 f6 test %esi,%esi 2d3: 75 5a jne32f 2d5: 8b 54 24 14 mov0x14(%esp),%edx 2d9: c1 e9 08shr$0x8,%ecx 2dc: 89 d8 mov%ebx,%eax 2de: 83 e1 3fand$0x3f,%ecx 2e1: e8 e3 fe ff ff call 1c9 2e6: 85 c0 test %eax,%eax 2e8: 75 45 jne32f 2ea: 8b 4b 04mov0x4(%ebx),%ecx 2ed: 8b 54 24 18 mov0x18(%esp),%edx 2f1: 89 d8 mov%ebx,%eax 2f3: c1 e9 0eshr$0xe,%ecx 2f6: 83 e1 3fand$0x3f,%ecx 2f9: e8 cb fe ff ff call 1c9 2fe: 85 c0 test %eax,%eax 300: 75 2d jne32f 302: 8b 4b 04mov0x4(%ebx),%ecx 305: 8d 93 10 0c 00 00 lea0xc10(%ebx),%edx 30b: 89 d8 mov%ebx,%eax 30d: c1 e9 14shr$0x14,%ecx 310: 83 e1 3fand$0x3f,%ecx 313: e8 b1 fe ff ff call 1c9 318: 85 c0 test %eax,%eax 31a: 75 13 jne32f 31c: 8b 4b 04mov0x4(%ebx),%ecx 31f: 8d 93 10 0e 00 00 lea0xe10(%ebx),%edx 325: 89 d8 mov%ebx,%eax 327: c1 e9 1ashr$0x1a,%ecx 32a: e8 9a fe ff ff call 1c9 32f: 8d 0c f3lea(%ebx,%esi,8),%ecx 332: ff 43 04incl 0x4(%ebx) 335: 8d 54 24 1c lea0x1c(%esp),%edx 339: 8b 71 10mov0x10(%ecx),%esi 33c: 8d 41 10lea0x10(%ecx),%eax 33f: 89 54 24 10 mov%edx,0x10(%esp) 343: 89 56 04mov%edx,0x4(%esi) 346: 89 74 24 1c mov%esi,0x1c(%esp) 34a: 8b 71 14mov0x14(%ecx),%esi 34d: 89 74 24 20 mov%esi,0x20(%esp) 351: 89 16 mov%edx,(%esi) 353: 89 41 10mov%eax,0x10(%ecx) 356: 89 40 04mov%eax,0x4(%eax) 359: 8b 74 24 1c mov0x1c(%esp),%esi 35d: 3b 74 24 10 cmp0x10(%esp),%esi 361: 0f 84 57 ff ff ff je 2be 367: 8b 46 0cmov0xc(%esi),%eax 36a: 8b 4e 20mov0x20(%esi),%ecx 36d: 8b 7e 10mov0x10(%esi),%edi 370: 8b 6e 14mov0x14(%esi),%ebp 373: 89 c2 mov%eax,%edx 375: 83 e2 02and$0x2,%edx 378: 85 c9 test %ecx,%ecx 37a: 89 54 24 0c mov%edx,0xc(%esp) 37e: 74 1b je 39b 380: 83 e0 01and$0x1,%eax 383: 8b 56 1cmov0x1c(%esi),%edx 386: 89 3c 24mov%edi,(%esp) 389: 89 44 24 08 mov%eax,0x8(%esp) 38d: 8d 46 24lea0x24(%esi),%eax 390: 89 44 24 04 mov%eax,0x4(%esp) 394: 89 f0 mov%esi,%eax 396: e8 fc ff ff ff call 397 39b: 89 33 mov%esi,(%ebx) 39d: 8b 16 mov(%esi),%edx 39f: 8b 46 04mov0x4(%esi),%eax 3a2: 89 42 04mov%eax,0x4(%edx) 3a5: 89 10 mov%edx,(%eax) 3a7: f6 46 0c 01 testb $0x1,0xc(%esi) 3ab: c7 06 00 00 00 00 movl $0x0,(%esi) 3b1: c7 46 04 00 02 20 00movl
[PATCH] mpt2sas: don't handle broadcast primitives
The handling of broadcast primitives involves
_scsih_block_io_all_device(), which does what the name implies. I have
observed cases with >60s of blocking io on all devices, caused by a
single bad device. The downsides of this code are obvious, while the
upsides are more elusive.
Signed-off-by: Joern Engel
---
drivers/scsi/mpt2sas/mpt2sas_base.c |4 -
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 238 --
2 files changed, 242 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 21c0a27..bba2209 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -586,9 +586,6 @@ _base_display_event_data(struct MPT2SAS_ADAPTER *ioc,
printk("\n");
return;
}
- case MPI2_EVENT_SAS_BROADCAST_PRIMITIVE:
- desc = "SAS Broadcast Primitive";
- break;
case MPI2_EVENT_SAS_INIT_DEVICE_STATUS_CHANGE:
desc = "SAS Init Device Status Change";
break;
@@ -4370,7 +4367,6 @@ mpt2sas_base_attach(struct MPT2SAS_ADAPTER *ioc)
/* here we enable the events we care about */
_base_unmask_events(ioc, MPI2_EVENT_SAS_DISCOVERY);
- _base_unmask_events(ioc, MPI2_EVENT_SAS_BROADCAST_PRIMITIVE);
_base_unmask_events(ioc, MPI2_EVENT_SAS_TOPOLOGY_CHANGE_LIST);
_base_unmask_events(ioc, MPI2_EVENT_SAS_DEVICE_STATUS_CHANGE);
_base_unmask_events(ioc, MPI2_EVENT_SAS_ENCL_DEVICE_STATUS_CHANGE);
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 3fffb95..856a502 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -2915,31 +2915,6 @@ _scsih_fw_event_cleanup_queue(struct MPT2SAS_ADAPTER
*ioc)
}
/**
- * _scsih_ublock_io_all_device - unblock every device
- * @ioc: per adapter object
- *
- * change the device state from block to running
- */
-static void
-_scsih_ublock_io_all_device(struct MPT2SAS_ADAPTER *ioc)
-{
- struct MPT2SAS_DEVICE *sas_device_priv_data;
- struct scsi_device *sdev;
-
- shost_for_each_device(sdev, ioc->shost) {
- sas_device_priv_data = sdev->hostdata;
- if (!sas_device_priv_data)
- continue;
- if (!sas_device_priv_data->block)
- continue;
- sas_device_priv_data->block = 0;
- dewtprintk(ioc, sdev_printk(KERN_INFO, sdev, "device_running, "
- "handle(0x%04x)\n",
- sas_device_priv_data->sas_target->handle));
- scsi_internal_device_unblock(sdev, SDEV_RUNNING);
- }
-}
-/**
* _scsih_ublock_io_device - set the device state to SDEV_RUNNING
* @ioc: per adapter object
* @handle: device handle
@@ -2971,34 +2946,6 @@ _scsih_ublock_io_device(struct MPT2SAS_ADAPTER *ioc, u64
sas_address)
}
/**
- * _scsih_block_io_all_device - set the device state to SDEV_BLOCK
- * @ioc: per adapter object
- * @handle: device handle
- *
- * During device pull we need to appropiately set the sdev state.
- */
-static void
-_scsih_block_io_all_device(struct MPT2SAS_ADAPTER *ioc)
-{
- struct MPT2SAS_DEVICE *sas_device_priv_data;
- struct scsi_device *sdev;
-
- shost_for_each_device(sdev, ioc->shost) {
- sas_device_priv_data = sdev->hostdata;
- if (!sas_device_priv_data)
- continue;
- if (sas_device_priv_data->block)
- continue;
- sas_device_priv_data->block = 1;
- dewtprintk(ioc, sdev_printk(KERN_INFO, sdev, "device_blocked, "
- "handle(0x%04x)\n",
- sas_device_priv_data->sas_target->handle));
- scsi_internal_device_block(sdev);
- }
-}
-
-
-/**
* _scsih_block_io_device - set the device state to SDEV_BLOCK
* @ioc: per adapter object
* @handle: device handle
@@ -5829,166 +5776,6 @@ _scsih_sas_enclosure_dev_status_change_event(struct
MPT2SAS_ADAPTER *ioc,
}
/**
- * _scsih_sas_broadcast_primitive_event - handle broadcast events
- * @ioc: per adapter object
- * @fw_event: The fw_event_work object
- * Context: user.
- *
- * Return nothing.
- */
-static void
-_scsih_sas_broadcast_primitive_event(struct MPT2SAS_ADAPTER *ioc,
-struct fw_event_work *fw_event)
-{
- struct scsi_cmnd *scmd;
- unsigned long ser_no;
- struct scsi_device *sdev;
- u16 smid, handle;
- u32 lun;
- struct MPT2SAS_DEVICE *sas_device_priv_data;
- u32 termination_count;
- u32 query_count;
- Mpi2SCSITaskManagementReply_t *mpi_reply;
- Mpi2EventDataSasBroadcastPrimitive_t *event_data = fw_event->event_data;
- u16 ioc_status;
- unsigned long flags;
- int r;
- u8 max_retries = 0;
- u8 task_abort_retries;
-
- mutex_lock(>tm_cmds.mutex);
- dewtprintk(ioc,
Re: [PATCH] mpt2sas: don't handle broadcast primitives
On Fri, 19 July 2013 18:06:59 -0400, Jörn Engel wrote: > > The handling of broadcast primitives involves > _scsih_block_io_all_device(), which does what the name implies. I have > observed cases with >60s of blocking io on all devices, caused by a > single bad device. The downsides of this code are obvious, while the > upsides are more elusive. And since this patch looks more like an April fools joke: I have gathered a few machine-months of testing, including tortures that specifically stress the removed codepaths. This is a serious submission and unless someone can show me a _very_ good reason for keeping the deleted code, I would like to get it merged. Jörn -- Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success." -- Tom DeMarco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: msm: Add support for MSM TLMM pinmux
On 07/11/13 20:26, Hanumant Singh wrote:
> +
> +MODULE_AUTHOR("Hanumant Singh ");
> +MODULE_LICENSE("GPLv2");
Doesn't this need to be "GPL v2"?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote: > On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote: > > > > The issue here seems to be the dynamic binding nature of the crypto > > subsystem. When something needs crypto, it will request the appropriate > > crypto module (e.g. crct10dif), which may race with detecting a specific > > hardware accelerator based on CPUID or device information (e.g. > > crct10dif_pclmul). > > > > RAID has effectively the same issue, and we just "solved" it by > > compiling in all the accelerators into the top-level module. > > I think for crypto the simplest solution is to not do CPUID-based > loading. Then crypto users will simply load the module alias which > causes modprobe to load all modules providing that alias. > > Cheers, Herbert, I've tried the module alias approach (see my earlier mail with patch) but it didn't seem to load things properly. Can you check to see if there's anything I did incorrectly. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On 07/19/2013 04:26 PM, Greg Kroah-Hartman wrote: >> >> RAID has effectively the same issue, and we just "solved" it by >> compiling in all the accelerators into the top-level module. > > Then there's nothing to be done in udev or kmod, right? > I don't know. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: fix a bug when we try to open a file with O_TMPFILE flag
On Fri, Jul 19, 2013 at 08:14:05PM +0800, Zheng Liu wrote: > Hi Dave, > > After applied this patch, the problem has been fixed in my own sand box. > But that would be great if you could give it a try. I want to make sure > that this patch can fix the problem. It looks like there has the same > problem in ext3. So if this patch is fine, I will generate a patch for > ext3 file system. Nice catch, and you have my ACK. Which tree do you prefer that to go through? vfs and ext4 are the obvious candidates... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] [SCSI] sg: no need sg_open_exclusive_lock
On Wed, 17 July 2013 23:34:04 +0800, Vaughan Cao wrote: > Date: Wed, 17 Jul 2013 23:34:04 +0800 > From: Vaughan Cao > To: jo...@logfs.org > Cc: dgilb...@interlog.com, jbottom...@parallels.com, > linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org, > vaughan@oracle.com > Subject: [PATCH v4 2/4] [SCSI] sg: no need sg_open_exclusive_lock > X-Mailer: git-send-email 1.7.11.7 > > Open exclusive check is protected by o_sem, no need sg_open_exclusive_lock. > @exclude is used to record which type of rwsem we are holding. > > Signed-off-by: Vaughan Cao Reviewed-by: Joern Engel Jörn -- "Error protection by error detection and correction." -- from a university class -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] [SCSI] sg: use rwsem to solve race during exclusive open
On Wed, 17 July 2013 23:34:03 +0800, Vaughan Cao wrote: > Date: Wed, 17 Jul 2013 23:34:03 +0800 > From: Vaughan Cao > To: jo...@logfs.org > Cc: dgilb...@interlog.com, jbottom...@parallels.com, > linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org, > vaughan@oracle.com > Subject: [PATCH v4 1/4] [SCSI] sg: use rwsem to solve race during > exclusive open > X-Mailer: git-send-email 1.7.11.7 > > A race condition may happen if two threads are both trying to open the same sg > with O_EXCL simultaneously. It's possible that they both find fsds list is > empty and get_exclude(sdp) returns 0, then they both call set_exclude() and > break out from wait_event_interruptible and resume open. > > Now use rwsem to protect this process. Exclusive open gets write lock and > others get read lock. The lock will be held until file descriptor is closed. > This also leads 'exclude' only a status rather than a check mark. > > Signed-off-by: Vaughan Cao Reviewed-by: Joern Engel Jörn -- When you close your hand, you own nothing. When you open it up, you own the whole world. -- Li Mu Bai in Tiger & Dragon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote: > On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote: > > > > udev isn't doing any module loading, 'modprobe' is just being called for > > any new module alias that shows up in the system, and all of the drivers > > that match it then get loaded. > > > > How is it a problem if a module is attempted to be loaded that is > > already loaded? How is it a problem if a different module is loaded for > > a device already bound to a driver? Both of those should be total > > "no-ops" for the kernel. > > > > But, I don't know anything about the cpu code, how is loading a module > > causing problems? That sounds like it needs to be fixes, as any root > > user can load modules whenever they want, you can't protect the kernel > > from doing that. > > > > The issue here seems to be the dynamic binding nature of the crypto > subsystem. When something needs crypto, it will request the appropriate > crypto module (e.g. crct10dif), which may race with detecting a specific > hardware accelerator based on CPUID or device information (e.g. > crct10dif_pclmul). > > RAID has effectively the same issue, and we just "solved" it by > compiling in all the accelerators into the top-level module. Then there's nothing to be done in udev or kmod, right? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote: > > The issue here seems to be the dynamic binding nature of the crypto > subsystem. When something needs crypto, it will request the appropriate > crypto module (e.g. crct10dif), which may race with detecting a specific > hardware accelerator based on CPUID or device information (e.g. > crct10dif_pclmul). > > RAID has effectively the same issue, and we just "solved" it by > compiling in all the accelerators into the top-level module. I think for crypto the simplest solution is to not do CPUID-based loading. Then crypto users will simply load the module alias which causes modprobe to load all modules providing that alias. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote: > > udev isn't doing any module loading, 'modprobe' is just being called for > any new module alias that shows up in the system, and all of the drivers > that match it then get loaded. > > How is it a problem if a module is attempted to be loaded that is > already loaded? How is it a problem if a different module is loaded for > a device already bound to a driver? Both of those should be total > "no-ops" for the kernel. > > But, I don't know anything about the cpu code, how is loading a module > causing problems? That sounds like it needs to be fixes, as any root > user can load modules whenever they want, you can't protect the kernel > from doing that. > The issue here seems to be the dynamic binding nature of the crypto subsystem. When something needs crypto, it will request the appropriate crypto module (e.g. crct10dif), which may race with detecting a specific hardware accelerator based on CPUID or device information (e.g. crct10dif_pclmul). RAID has effectively the same issue, and we just "solved" it by compiling in all the accelerators into the top-level module. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/72] 3.10.2-stable review
On 07/19/2013 09:32 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.2 release. > There are 72 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 21 05:25:08 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.86, 3.4.54, 3.9.10, and 3.10.1 3.9.11-rc1 patch failed to build: x64-64, mipsel, mips, powerpc, and tile: build failed with the following error: LD ipc/built-in.o CC [M] fs/cifs/inode.o fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’: fs/cifs/inode.c:560:4: error: implicit declaration of function ‘cifs_dbg’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [fs/cifs/inode.o] Error 1 make[1]: *** [fs/cifs] Error 2 make: *** [fs] Error 2 make: *** Waiting for unfinished jobs CC security/selinux/hooks.o I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled. cifs_dbg() is not defined. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.54-rc1, 3.9.10-rc1, 3.10.2-rc2) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y, and 3.10.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.9.y, and 3.10.y mips: defconfig passed on all, except 3.9.10 mipsel: defconfig passed on all, except 3.9.10 powerpc: wii_defconfig passed on all, except 3.9.10 sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all, except 3.9.10 -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/24] 3.4.54-stable review
On 07/19/2013 05:17 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.54 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Jul 21 02:23:13 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.54-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.86, 3.4.54, 3.9.10, and 3.10.1 3.9.11-rc1 patch failed to build: x64-64, mipsel, mips, powerpc, and tile: build failed with the following error: LD ipc/built-in.o CC [M] fs/cifs/inode.o fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’: fs/cifs/inode.c:560:4: error: implicit declaration of function ‘cifs_dbg’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [fs/cifs/inode.o] Error 1 make[1]: *** [fs/cifs] Error 2 make: *** [fs] Error 2 make: *** Waiting for unfinished jobs CC security/selinux/hooks.o I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled. cifs_dbg() is not defined. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.54-rc1, 3.9.10-rc1, 3.10.2-rc2) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.87-rc1, 3.4.54-rc1, 3.9.10-rc1?, and 3.10.2-rc2) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y, and 3.10.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.9.y, and 3.10.y mips: defconfig passed on all, except 3.9.10 mipsel: defconfig passed on all, except 3.9.10 powerpc: wii_defconfig passed on all, except 3.9.10 sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all, except 3.9.10 -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux-firmware/AMD: add readme files for amd-ucode
File: README File: microcode_amd.bin.README File: microcode_amd_fam15h.bin.README Signed-off-by: Sherry Hurwitz --- amd-ucode/README | 46 + amd-ucode/microcode_amd.bin.README| 29 ++ amd-ucode/microcode_amd_fam15h.bin.README | 13 3 files changed, 88 insertions(+) create mode 100644 amd-ucode/README create mode 100644 amd-ucode/microcode_amd.bin.README create mode 100644 amd-ucode/microcode_amd_fam15h.bin.README diff --git a/amd-ucode/README b/amd-ucode/README new file mode 100644 index 000..a92831d --- /dev/null +++ b/amd-ucode/README @@ -0,0 +1,46 @@ +This package provides latest microcode patches +for AMD processor families >= 0x10. + +See http://www.amd64.org/support/microcode.html +for details. + +Microcode patches are included in container files: +- 'microcode_amd.bin' (for AMD CPU families 10h - 14h) +- 'microcode_amd_fam15h.bin' (for AMD CPU family 15h) + +Please read the file INSTALL for install instructions. +Please read the file LICENSE for licensing information. + +The container files include following microcode patches: + +mc_patch_0183_PUB-v4/mc_patch_0183.asm +mc_patch_0184_PUB-v4/mc_patch_0184.asm +mc_patch_01C7_PUB-v1/mc_patch_01C7.asm +mc_patch_01C8_PUB-v1/mc_patch_01C8.asm +mc_patch_01D9_PUB-v1/mc_patch_01D9.asm +mc_patch_01DA_PUB-v1/mc_patch_01DA.asm +mc_patch_01DB_PUB-v1/mc_patch_01DB.asm +mc_patch_01DC_PUB-v1/mc_patch_01DC.asm +mc_patch_0232_PUB-v3/mc_patch_0232.asm +mc_patch_0327_PUB-v1/mc_patch_0327.asm +mc_patch_0529_PUB-v1/mc_patch_0529.asm +mc_patch_05000119_PUB-v1/mc_patch_05000119.asm +mc_patch_0600063D_PUB-v1/mc_patch_0600063D.asm +mc_patch_06000822_PUB-v1/mc_patch_06000822.asm +mc_patch_06001119_PUB-v2/mc_patch_06001119.asm + +*** +Copyright 2008-2013 ADVANCED MICRO DEVICES, INC. All Rights Reserved. + +AMD is granting you permission to use this software and documentation +(if any) (collectively, the “Materials”) pursuant to the terms and +conditions of the Software License Agreement included with the +Materials. This header does NOT give you permission to use the +Materials or any rights under AMD’s intellectual property. Your use +of any portion of these Materials shall constitute your acceptance of +those terms and conditions. If you do not agree to the terms and +conditions of the Software License Agreement, you do not have +permission to use any portion of these Materials. If you do not have +a copy of the Software License Agreement, contact your AMD +representative for a copy. + diff --git a/amd-ucode/microcode_amd.bin.README b/amd-ucode/microcode_amd.bin.README new file mode 100644 index 000..617d951 --- /dev/null +++ b/amd-ucode/microcode_amd.bin.README @@ -0,0 +1,29 @@ +;** +; The associated microcode container file fixes the errata as documented in +; Revision Guide for AMD Family 10h Processors, order #41322, +; Revision Guide for AMD Family 11h Processors, order #41788, +; Revision Guide for AMD Family 12h Processors, order #44739, +; Revision Guide for AMD Family 14h Models 00h-0Fh Processors, order #47534, +; for different revisions of AMD processors as follows: +; +; CPUIDFn[_0001]_EAX; ID; Errata fixed; +; +; 0x00100F22; 0x0183; 244, 260, 280, 302, 308, 315, 342; +; 0x00100F23; 0x0183; 244, 260, 280, 302, 308, 315, 342; +; 0x00100F2A; 0x0184; 244, 260, 280, 302, 308, 315, 342; +; 0x00100F42; 0x01DB; 342, 440, 573; +; 0x00100F43; 0x01C8; 407, 440; +; 0x00100F52; 0x01DB; 342, 440, 573; +; 0x00100F53; 0x01C8; 407, 440; +; 0x00100F62; 0x01C7; 407, 440; +; 0x00100F63; 0x01C8; 407, 440; +; 0x00100F80; 0x01DA; 419, 440, 573; +; 0x00100F81; 0x01D9; #406, #407, #440, #573, #669; +; 0x00100F91; 0x01D9; #406, #407, #440, #573, #669; +; 0x00100FA0; 0x01DC; 438, 440, 573; +; 0x00200F31; 0x0232; 311, 316; +; 0x00300F10; 0x0327; #564, #573, #662, #686; +; 0x00500F10; 0x0529; #461, #564, #594, #595, #784; +; 0x00500F20; 0x05000119; #461, #564, #594, #639, #662, #686, #784; +; +;** diff --git a/amd-ucode/microcode_amd_fam15h.bin.README b/amd-ucode/microcode_amd_fam15h.bin.README new file mode 100644 index 000..a688b84 --- /dev/null +++ b/amd-ucode/microcode_amd_fam15h.bin.README @@ -0,0 +1,13 @@ +;** +; The associated microcode container file fixes
Re: [PATCH] mm: vmstats: track TLB flush stats on UP too
On Fri, 19 Jul 2013 13:40:04 -0700 Dave Hansen wrote:
>
> Andrew, this fixes up the TLB flush vmstats for UP. It's on top
> of the previous patch, but I'm happy to combine them and send a
> replacement if you'd prefer.
>
> This also removes the NR_TLB_LOCAL_FLUSH_ONE_KERNEL counter. We
> do not have a good API on UP to separate out the kernel from the
> non-kernel flushes. It's probably not an important distinction
> anyway.
>
> Compile and boot tested on 64-bit SMP and UP. Compile tested
> for x86_32 SMP.
>
> --
>
> The previous patch doing vmstats for TLB flushes effectively
> missed UP since arch/x86/mm/tlb.c is only compiled for SMP.
>
> UP systems do not do remote TLB flushes, so compile those
> counters out on UP.
>
> arch/x86/kernel/cpu/mtrr/generic.c calls __flush_tlb() directly.
> This is probably an optimization since both the mtrr code and
> __flush_tlb() write cr4. It would probably be safe to make that
> a flush_tlb_all() (and then get these statistics), but the mtrr
> code is ancient and I'm hesitant to touch it other than to just
> stick in the counters.
Do we really want to do this? I agree that UP isn't super-important,
particularly on x86, and the benefit here is small.
Often I mention things just to check that they have been considered.
Considered-and-rejected is better than forgot-about-that.
> ...
>
> --- linux.git/include/linux/vm_event_item.h~compile-useless-stats-out-on-up
> 2013-07-19 08:21:37.408237538 -0700
> +++ linux.git-davehans/include/linux/vm_event_item.h 2013-07-19
> 09:13:16.903143205 -0700
> @@ -70,11 +70,12 @@ enum vm_event_item { PGPGIN, PGPGOUT, PS
> THP_ZERO_PAGE_ALLOC,
> THP_ZERO_PAGE_ALLOC_FAILED,
> #endif
> +#ifdef CONFIG_SMP
> NR_TLB_REMOTE_FLUSH,/* cpu tried to flush others' tlbs */
> NR_TLB_REMOTE_FLUSH_RECEIVED,/* cpu received ipi for flush */
> +#endif
> NR_TLB_LOCAL_FLUSH_ALL,
> NR_TLB_LOCAL_FLUSH_ONE,
> - NR_TLB_LOCAL_FLUSH_ONE_KERNEL,
> NR_VM_EVENT_ITEMS
I was all excited, expecting documentation for these as discussed
yesterday, but it was not to be :(
> +/* "_up" is for UniProcessor
> + *
> + * This is a helper for other header functions. *Not*
> + * intended to be called directly. All global TLB
> + * flushes need to either call this, or do the bump the
> + * vm statistics themselves.
> + */
Comment seems a bit sickly. Have a pill:
---
a/arch/x86/include/asm/tlbflush.h~mm-vmstats-track-tlb-flush-stats-on-up-too-fix
+++ a/arch/x86/include/asm/tlbflush.h
@@ -85,11 +85,10 @@ static inline void __flush_tlb_one(unsig
#ifndef CONFIG_SMP
-/* "_up" is for UniProcessor
+/* "_up" is for UniProcessor.
*
- * This is a helper for other header functions. *Not*
- * intended to be called directly. All global TLB
- * flushes need to either call this, or do the bump the
+ * This is a helper for other header functions. *Not* intended to be called
+ * directly. All global TLB flushes need to either call this, or to bump the
* vm statistics themselves.
*/
static inline void __flush_tlb_up(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] MFD: ti_tscadc: disable TSC config registers in adc mode
On Fri, Jul 19, 2013 at 09:47:16PM +0100, Zubair Lutfullah : wrote: > On Thu, Jul 18, 2013 at 03:45:55PM -0700, Greg KH wrote: > > > Did Rachna really sign off on this, and the other, patches? Or did they > Authored and signed off on it in their TI tree. based on 3.2. Ok, as long as they did that, it's fine to have those lines in the patch. As you didn't have them in the previous version, I had to ask. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote: > Alas, this is not the one I'd like to apply. > > With that patch applied, new device objects are created to avoid binding the > processor driver directly to the cpu system device objects, because that > apparently confuses udev and it starts to ignore the cpu modalias once the > driver has been bound to any of those objects. > > I've verified in the meantime that this indeed is the case. > > A link to the patch in question: https://patchwork.kernel.org/patch/2830561/ > > Greg, I asked you some time ago whether or not it was possible for udev to > stop > autoloading modules that matched the cpu modalias after a driver had been > bound > to the cpu system device objects and you said "no". However, this time I can > say with certainty that that really is the case. So, the question now is > whether or not we can do anything in the kernel to avoid that confusion in > udev > instead of applying the patch linked above (which is beyond ugly in my not so > humble opinion)? udev isn't doing any module loading, 'modprobe' is just being called for any new module alias that shows up in the system, and all of the drivers that match it then get loaded. How is it a problem if a module is attempted to be loaded that is already loaded? How is it a problem if a different module is loaded for a device already bound to a driver? Both of those should be total "no-ops" for the kernel. But, I don't know anything about the cpu code, how is loading a module causing problems? That sounds like it needs to be fixes, as any root user can load modules whenever they want, you can't protect the kernel from doing that. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v3.2.y][v3.5.y][3.8.y] Input: elantech - fix for newer hardware versions (v7)
Hi Joseph, On Fri, Jul 19, 2013 at 05:50:25PM -0400, Joseph Salisbury wrote: > Hello, > > Please consider including upstream commit > 9eebed7de660c0b5ab129a9de4f89d20b60de68c in the next v3.2.y, v3.5.y and > v3.8.y releases. > > It was included upstream as of v3.11-rc1. It has been tested and > confirmed to resolve http://bugs.launchpad.net/bugs/1166442 . > > commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c > Author: Matteo Delfino > Date: Sat Jul 6 21:52:26 2013 -0700 > > Input: elantech - fix for newer hardware versions (v7) > > This fix came into my mailbox on July 06, so fairly recently. I would prefer if we went through a few more -rcs before sending it to stable. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote: Hi Scott, > What specifically should I do to test it? Could you double check perf annotate works? I'm 99% sure it will but that is what was failing on ppc64. I'm not really sure what it's supposed to look like when "perf annotate" works. It spits a bunch of unreadable[1] dark-blue-on-black assembly code at me, all with "0.00 :" in the left column. Oh, wait -- some lines have "100.00 : " on the left, in even-more-unreadable dark-red-on-black. Apart from the annoying colors, is there anything specific I should be looking for? Some sort of error message, or output that actually makes sense? I've attached the output from "perf annotate" and "perf report". perf.data was generated by "perf record find /usr > /dev/null" on an NFS root (which took a few seconds to complete), so the large amount of __alloc_skb makes some sense, but the way perf annotate shows 100% on one instruction in each function seems odd. -Scott [1] ...unless I crank the brightness up on my monitor to the point where whites are blinding, or redirect the output to a file so the colors go away. Percent | Source code & Disassembly of vmlinux : : : : Disassembly of section .text: : : c0097510 : 0.00 : c0097510: 94 21 ff a0 stwur1,-96(r1) 0.00 : c0097514: 7c 08 02 a6 mflrr0 0.00 : c0097518: bf 01 00 40 stmwr24,64(r1) 0.00 : c009751c: 7c 7e 1b 78 mr r30,r3 0.00 : c0097520: 90 01 00 64 stw r0,100(r1) 0.00 : c0097524: 3b 80 00 00 li r28,0 0.00 : c0097528: 3b 63 04 68 addir27,r3,1128 0.00 : c009752c: 3b 40 00 00 li r26,0 0.00 : c0097530: 87 bb 00 04 lwzur29,4(r27) 0.00 : c0097534: 2f 9d 00 00 cmpwi cr7,r29,0 0.00 : c0097538: 41 9e 00 1c beq-cr7,c0097554 0.00 : c009753c: 7f 00 00 a6 mfmsr r24 0.00 : c0097540: 7c 00 01 46 .long 0x7c000146 0.00 : c0097544: 80 1d 00 3c lwz r0,60(r29) 0.00 : c0097548: 2f 80 00 00 cmpwi cr7,r0,0 0.00 : c009754c: 40 9e 00 c4 bne-cr7,c0097610 0.00 : c0097550: 7f 00 01 06 .long 0x7f000106 100.00 : c0097554: 2f 9c 00 01 cmpwi cr7,r28,1 0.00 : c0097558: 3b 9c 00 01 addir28,r28,1 0.00 : c009755c: 40 be ff d4 bne-cr7,c0097530 0.00 : c0097560: 3d 20 c0 72 lis r9,-16270 0.00 : c0097564: 80 09 99 50 lwz r0,-26288(r9) 0.00 : c0097568: 2f 80 00 00 cmpwi cr7,r0,0 0.00 : c009756c: 41 be 00 88 beq+cr7,c00975f4 0.00 : c0097570: 3b e1 00 08 addir31,r1,8 0.00 : c0097574: 38 00 00 00 li r0,0 0.00 : c0097578: 39 20 00 03 li r9,3 0.00 : c009757c: 38 9e 01 d8 addir4,r30,472 0.00 : c0097580: 38 a0 00 10 li r5,16 0.00 : c0097584: 7f e3 fb 78 mr r3,r31 0.00 : c0097588: 90 01 00 1c stw r0,28(r1) 0.00 : c009758c: 90 01 00 20 stw r0,32(r1) 0.00 : c0097590: 90 01 00 28 stw r0,40(r1) 0.00 : c0097594: 90 01 00 2c stw r0,44(r1) 0.00 : c0097598: 90 01 00 30 stw r0,48(r1) 0.00 : c009759c: 91 21 00 24 stw r9,36(r1) 0.00 : c00975a0: 90 01 00 08 stw r0,8(r1) 0.00 : c00975a4: 90 01 00 0c stw r0,12(r1) 0.00 : c00975a8: 90 01 00 10 stw r0,16(r1) 0.00 : c00975ac: 90 01 00 14 stw r0,20(r1) 0.00 : c00975b0: 93 c1 00 18 stw r30,24(r1) 0.00 : c00975b4: 48 1a 05 8d bl c0237b40 0.00 : c00975b8: 7f e3 fb 78 mr r3,r31 0.00 : c00975bc: 4b f8 0e 89 bl c0018444 0.00 : c00975c0: 3c 80 c0 09 lis r4,-16375 0.00 : c00975c4: 39 23 00 08 addir9,r3,8 0.00 : c00975c8: 93 e1 00 1c stw r31,28(r1) 0.00 : c00975cc: 55 29 00 38 rlwinm r9,r9,0,0,28 0.00 : c00975d0: 3c 60 c0 09 lis r3,-16375 0.00 : c00975d4: 38 09 00 10 addir0,r9,16 0.00 : c00975d8: 91 21 00 20 stw r9,32(r1) 0.00 : c00975dc: 38 63 fd 80 addir3,r3,-640 0.00 : c00975e0: 38 84 65 50 addir4,r4,25936 0.00 : c00975e4: 38 a1 00 18 addir5,r1,24 0.00 : c00975e8: b0 01 00 2a sth r0,42(r1)
Re: [PATCH v4 3/4] [SCSI] sg: checking sdp->detached isn't protected when open
On Wed, 17 July 2013 23:34:05 +0800, Vaughan Cao wrote:
>
> -static Sg_fd *sg_add_sfp(Sg_device * sdp, int dev);
> +static Sg_fd *sg_add_sfp(Sg_device * sdp, int dev, int * reason);
You can use ERR_PTR and friends instead of adding another parameter.
> static void sg_remove_sfp(struct kref *);
> static Sg_request *sg_get_rq_mark(Sg_fd * sfp, int pack_id);
> static Sg_request *sg_add_request(Sg_fd * sfp);
> @@ -295,21 +295,14 @@ sg_open(struct inode *inode, struct file *filp)
> if (flags & O_EXCL)
> sdp->exclude = 1; /* used by release lock */
>
> - if (sdp->detached) {
> - retval = -ENODEV;
> - goto sem_out;
> - }
> if (sfds_list_empty(sdp)) { /* no existing opens on this device */
> sdp->sgdebug = 0;
> q = sdp->device->request_queue;
> sdp->sg_tablesize = queue_max_segments(q);
> }
> - if ((sfp = sg_add_sfp(sdp, dev)))
> - filp->private_data = sfp;
> - else {
> - retval = -ENOMEM;
> + if (!(sfp = sg_add_sfp(sdp, dev, )))
> goto sem_out;
> - }
sfp = sg_add_sfp(sdp, dev);
if (IS_ERR(sfp)) {
retval = PTR_ERR(sfp);
goto sem_out;
}
> + filp->private_data = sfp;
> retval = 0;
>
> if (retval) {
> @@ -2047,15 +2040,18 @@ sg_remove_request(Sg_fd * sfp, Sg_request * srp)
> }
>
> static Sg_fd *
> -sg_add_sfp(Sg_device * sdp, int dev)
> +sg_add_sfp(Sg_device * sdp, int dev, int * reason)
> {
> Sg_fd *sfp;
> unsigned long iflags;
> int bufflen;
>
> sfp = kzalloc(sizeof(*sfp), GFP_ATOMIC | __GFP_NOWARN);
> - if (!sfp)
> + if (!sfp) {
> + if (reason)
> + *reason = -ENOMEM;
> return NULL;
> + }
if (!sfp)
return ERR_PTR(-ENOMEM);
Jörn
--
Luck is when opportunity meets good preparation.
-- Chinese proverb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] [SCSI] sg: push file descriptor list locking down to per-device locking
On Wed, 17 July 2013 23:34:06 +0800, Vaughan Cao wrote: > Date: Wed, 17 Jul 2013 23:34:06 +0800 > From: Vaughan Cao > To: jo...@logfs.org > Cc: dgilb...@interlog.com, jbottom...@parallels.com, > linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org, > vaughan@oracle.com > Subject: [PATCH v4 4/4] [SCSI] sg: push file descriptor list locking down > to per-device locking > X-Mailer: git-send-email 1.7.11.7 > > Push file descriptor list locking down to per-device locking. Let > sg_index_lock > only protect device lookup. > sdp->detached is also set and checked with this lock held. > > Signed-off-by: Vaughan Cao Reviewed-by: Joern Engel Jörn -- What one programmer can do in one month, two programmers can do in two months. -- Fred Brooks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mlockall triggred rcu_preempt stall.
On Fri, Jul 19, 2013 at 10:53:23AM -0400, Dave Jones wrote:
> My fuzz tester keeps hitting this. Every instance shows the non-irq stack
> came in from mlockall. I'm only seeing this on one box, but that has more
> ram (8gb) than my other machines, which might explain it.
Are you building CONFIG_PREEMPT=n? I don't see any preemption points in
do_mlockall(), so a range containing enough vmas might well stall the
CPU in that case.
Does the patch below help? If so, we probably need others, but let's
first see if this one helps. ;-)
CCing the MM guys and those who have most recently touched do_mlockall()
for their insight as well.
Thanx, Paul
> Dave
mm: Place preemption point in do_mlockall() loop
There is a loop in do_mlockall() that lacks a preemption point, which
means that the following can happen on non-preemptible builds of the
kernel:
> My fuzz tester keeps hitting this. Every instance shows the non-irq stack
> came in from mlockall. I'm only seeing this on one box, but that has more
> ram (8gb) than my other machines, which might explain it.
>
> Dave
>
> INFO: rcu_preempt self-detected stall on CPU { 3} (t=6500 jiffies g=470344
> c=470343 q=0)
> sending NMI to all CPUs:
> NMI backtrace for cpu 3
> CPU: 3 PID: 29664 Comm: trinity-child2 Not tainted 3.11.0-rc1+ #32
> task: 88023e743fc0 ti: 88022f6f2000 task.ti: 88022f6f2000
> RIP: 0010:[] []
> trace_hardirqs_off_caller+0x21/0xb0
> RSP: 0018:880244e03c30 EFLAGS: 0046
> RAX: 88023e743fc0 RBX: 0001 RCX: 003c
> RDX: 000f RSI: 0004 RDI: 81033cab
> RBP: 880244e03c38 R08: 880243288a80 R09: 0001
> R10: R11: 0001 R12: 880243288a80
> R13: 8802437eda40 R14: 0008 R15: d010
> FS: 7f50ae33b740() GS:880244e0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0097f000 CR3: 000240fa CR4: 001407e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0600
> Stack:
> 810bf86d 880244e03c98 81033cab 0096
> d008 00030002 0004 0003
> 2710 81c50d00 81c50d00 880244fcde00
> Call Trace:
>
> [] ? trace_hardirqs_off+0xd/0x10
> [] __x2apic_send_IPI_mask+0x1ab/0x1c0
> [] x2apic_send_IPI_all+0x1c/0x20
> [] arch_trigger_all_cpu_backtrace+0x65/0xa0
> [] rcu_check_callbacks+0x331/0x8e0
> [] ? hrtimer_run_queues+0x20/0x180
> [] ? sched_clock_cpu+0xb5/0x100
> [] update_process_times+0x47/0x80
> [] tick_sched_handle.isra.16+0x25/0x60
> [] tick_sched_timer+0x41/0x60
> [] __run_hrtimer+0x81/0x4e0
> [] ? tick_sched_do_timer+0x60/0x60
> [] hrtimer_interrupt+0xff/0x240
> [] local_apic_timer_interrupt+0x34/0x60
> [] smp_apic_timer_interrupt+0x3f/0x60
> [] apic_timer_interrupt+0x6f/0x80
> [] ? retint_restore_args+0xe/0xe
> [] ? __do_softirq+0xb1/0x440
> [] irq_exit+0xcd/0xe0
> [] smp_apic_timer_interrupt+0x45/0x60
> [] apic_timer_interrupt+0x6f/0x80
>
> [] ? retint_restore_args+0xe/0xe
> [] ? wait_for_completion_killable+0x170/0x170
> [] ? preempt_schedule_irq+0x53/0x90
> [] retint_kernel+0x26/0x30
> [] ? queue_work_on+0x43/0x90
> [] schedule_on_each_cpu+0xc9/0x1a0
> [] ? lru_add_drain+0x50/0x50
> [] lru_add_drain_all+0x15/0x20
> [] SyS_mlockall+0xa5/0x1a0
> [] tracesys+0xdd/0xe2
This commit addresses this problem by inserting the required preemption
point.
Reported-by: Dave Jones
Signed-off-by: Paul E. McKenney
Cc: KOSAKI Motohiro
Cc: Michel Lespinasse
Cc: Andrew Morton
Cc: Linus Torvalds
diff --git a/mm/mlock.c b/mm/mlock.c
index 79b7cf7..92022eb 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -506,6 +506,7 @@ static int do_mlockall(int flags)
/* Ignore errors */
mlock_fixup(vma, , vma->vm_start, vma->vm_end, newflags);
+ cond_resched();
}
out:
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.10.0 i386 uniprocessor panic
On 07/19/2013 02:00 PM, George Spelvin wrote: >>> EIP is at 0xc143a091 >>> EAX: c143a090 EBX: 0100 ECX: f315 EDX: c143a090 >>> ESI: c143a090 EDI: c143a090 EBP: c143a090 ESP: f3151eec >>> DS: 007b ES: 007b FS: GS: 0033 SS: 0068 >>> CR0: 80050033 CR2: a090c143 CR3: 331c6000 CR4: 07d0 >>> DR0: DR1: DR2: DR3: >>> DR6: 0ff0 DR7: 0400 > >>> (The CR2 value looks particularly odd.) > >> Indeed it does; it is a user space value, but it doesn't look like >> either a normal user space value nor really as a trivially buggered-up >> kernel pointer value, unless the 0xc143... at the bottom is the upper >> half of a kernel pointer, in which case we probably obtained this value >> from a corrupt, misaligned pointer. > > Er... I assumed you'd see instantly that it was the 0xc143a090 value > that's in 5 registers (EAX/EDX/ESI/EDI/EBP), and IP-1, but with the > halves swapped. That would have requiring me to actually pay attention. I claim undercaffeination. > How the heck the halves got swapped is confusing me... Disassembling the "code" (which is really data) makes it kind of obvious: C143A090 90nop C143A091 A043C190A0mov al,[0xa090c143] ; fault here We jumped into data which contained a series of self-pointers (presumably empty double-linked lists), and the first two bytes became opcodes... Unfortunately the disassembly of call_timer_fn.isra.37 doesn't really tell us anything other than that the passed-in value of %eax was bogus. It is *very* interesting, though, that that value is present in so many registers (in fact, the ONLY GPRs which didn't have that value are %ebx and %ecx, which are set by that function itself.) A disassembly of the calling function, i.e.: [] ? run_timer_softirq+0x150/0x165 ... would be a good idea, at least. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/22] ARM: ux500: Remove '0x's from Exynos5420 DTS file
On Fri, Jul 19, 2013 at 02:58:41PM +0100, Lee Jones wrote: > Cc: Kukjin Kim > Cc: linux-samsung-...@vger.kernel.org > Signed-off-by: Lee Jones > --- > arch/arm/boot/dts/exynos5420.dtsi | 2 +- One question. What have all these files got to do with ux500 ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Fri, 2013-07-19 at 21:46 +, James Bottomley wrote: > On Fri, 2013-07-19 at 14:22 -0700, Nicholas A. Bellinger wrote: > > On Wed, 2013-07-17 at 04:52 +, James Bottomley wrote: > > > On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: > > > > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: > > > > > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > > > > > > > > > > > Lets start with discussing this on the list, please, and then see > > > > > > where > > > > > > we go from there ... > > > > > > > > > > > > > > > > Yes, the discussion is beginning to make it's way to the list. I've > > > > > mostly been waiting for blk-mq to get a wider review before taking the > > > > > early scsi-mq prototype driver to a larger public audience. > > > > > > > > > > Primarily, I'm now reaching out to the people most effected by > > > > > existing > > > > > scsi_request_fn() based performance limitations. Most of them have > > > > > abandoned existing scsi_request_fn() based logic in favor of raw block > > > > > make_request() based drivers, and are now estimating the amount of > > > > > effort to move to an scsi-mq based approach. > > > > > > > > > > Regardless, as the prototype progresses over the next months, having a > > > > > face-to-face discussion with the key parties in the room would be very > > > > > helpful given the large amount of effort involved to actually make > > > > > this > > > > > type of generational shift in SCSI actually happen. > > > > > > > > There's a certain amount of overlap with the aio/O_DIRECT work as well. > > > > But if it's not a general session, could always be a BOF or something. > > > > > > > > I'll second the argument that most technical topics probably DO belong > > > > in a topic related workshop. But that leaves us with basically only > > > > process related topics at KS, I don't think it hurts to have a bit of > > > > tech meat on the bone too. At least I personally miss that part of KS > > > > from years gone by. > > > > > > Heh well, given that most of the block mq discussions at LSF have been > > > you saying you really should get around to cleaning up and posting the > > > code, you'll understand my wanting to see that happen first ... > > > > > > I suppose we could try to run a storage workshop within KS, but I think > > > most of the mini summit slots have already gone. > > > > That would be great, given there is a reasonable level of interest from > > various parities, and the pain threshold for existing scsi small block > > random I/O performance is high.. > > > > When will we know if there is a workshop / mini summit slot available..? > > > > (CC'ing Mike Christie as well for open-iscsi/scsi-mq bits) > > > > > There's also plumbers > > > if all slots are gone (I would say that, being biased and on the > > > programme committee) Ric is running the storage and Filesystems MC > > > > > > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159 > > > > FYI, I'm not trying to 'sell' scsi-mq to the larger community yet, but > > rather interested in getting the right scsi/block/LLD people in the same > > room at KS for an hour or two to discuss implementation details, given > > the scope of the effort involved. > > Well, so that's why I think plumbers might be a better venue: we'll have > more of the actual storage people there. Usually we get at most 2-3 > storage people to KS compared to the 25 or so we usually have at LSF ... > that makes KS not a very good venue for storage centric discussions. > The most relevant people for the discussion are Jens, Hannes, Christoph, Tejun, Martin, Mike, and you. I know these folks are regular attendees for KS, but typically not for plumbers, which is why I made this KS topic proposal in the first place. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: negative left shift count when PAGE_SHIFT > 20
On Fri, 19 Jul 2013 07:47:02 +0800 Jerry wrote: > 2013/7/19 Andrew Morton : > > On Fri, 19 Jul 2013 00:56:12 +0800 Jerry wrote: > > > >> When PAGE_SHIFT > 20, the result of "20 - PAGE_SHIFT" is negative. The > >> calculating here will generate an unexpected result. In addition, if > >> PAGE_SHIFT > 20, The memory size represented by numentries was already > >> integral multiple of 1MB. > >> > > > > If you tell me that you have a machine which has PAGE_SIZE=2MB and this > > was the only problem which prevented Linux from running on that machine > > then I'll apply the patch ;) > > > > Hi Morton: > I just "grep -rn "#define\s\+PAGE_SHIFT" arch/", and find the > PAGE_SHIFT in some architecture is very big. > such as the following in "arch/hexagon/include/asm/page.h" > > #ifdef CONFIG_PAGE_SIZE_256KB > #define PAGE_SHIFT 18 > #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_256KB > #endif > > #ifdef CONFIG_PAGE_SIZE_1MB > #define PAGE_SHIFT 20 > #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_1MB > #endif > . Good heavens. > In my patch, I think compiler would optimize "if (20 > PAGE_SIZE)", it > won't generate any machine instruction. Just a guarantee. Well the existing code is a bit silly looking. Why can't we just do /* round applicable memory size up to nearest megabyte */ if (PAGE_SHIFT < 20) numentries = round_up(nr_kernel_pages, (1 << 20)/PAGE_SIZE); or similar? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026
Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.
Tested-by: Eric Griffith
Tested-by: Kent Baxley
Cc: # v3.8+
Signed-off-by: Kamal Mostafa
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a416645..204c3ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -555,6 +555,7 @@ enum intel_sbi_destination {
#define QUIRK_PIPEA_FORCE (1<<0)
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
+#define QUIRK_NO_PCH_PWM_ENABLE (1<<3)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 85f3eb7..42e207e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9398,6 +9398,17 @@ static void quirk_invert_brightness(struct drm_device
*dev)
DRM_INFO("applying inverted panel brightness quirk\n");
}
+/*
+ * Some machines (Dell XPS13) suffer broken backlight controls if
+ * BLM_PCH_PWM_ENABLE is set.
+ */
+static void quirk_no_pcm_pwm_enable(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE;
+ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -9467,6 +9478,11 @@ static struct intel_quirk intel_quirks[] = {
/* Acer Aspire 4736Z */
{ 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
+
+ /* Dell XPS13 HD Sandy Bridge */
+ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
+ /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
+ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
};
static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 80bea1d..01b5a51 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -580,7 +580,8 @@ void intel_panel_enable_backlight(struct drm_device *dev,
POSTING_READ(reg);
I915_WRITE(reg, tmp | BLM_PWM_ENABLE);
- if (HAS_PCH_SPLIT(dev)) {
+ if (HAS_PCH_SPLIT(dev) &&
+ !(dev_priv->quirks & QUIRK_NO_PCH_PWM_ENABLE)) {
tmp = I915_READ(BLC_PWM_PCH_CTL1);
tmp |= BLM_PCH_PWM_ENABLE;
tmp &= ~BLM_PCH_OVERRIDE_ENABLE;
--
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][v3.2.y][v3.5.y][3.8.y] Input: elantech - fix for newer hardware versions (v7)
Hello, Please consider including upstream commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c in the next v3.2.y, v3.5.y and v3.8.y releases. It was included upstream as of v3.11-rc1. It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1166442 . commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c Author: Matteo Delfino Date: Sat Jul 6 21:52:26 2013 -0700 Input: elantech - fix for newer hardware versions (v7) Sincerely, Joseph Salisbury -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi
Good day. I am Sonia Kim Fung and I am contacting you regarding a transaction of a large funds in my possession which i will like to share with you.I will provide you with more information upon your interest and acknowledgement. I will await you. Yours, Mrs.Sonia Kim Fung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/10] backports: backport drvdata = NULL core driver fixes
From: "Luis R. Rodriguez"
The Linux kernel had tons of code which at times cleared the
drvdata upon probe failure or release. There are however a bunch
of drivers that didn't clear this.
Commit 0998d063 implmented clearing this upon device_release_driver()
and dealt with probe failure on driver_probe_device(). After this the
kernel was cleaned up separately with *tons* of patches to remove all
these driver specific settings given that the clearing is now done
internally by the device core.
Instead of ifdef'ing code back in for older code where it was properly
in place backport this by piggy backing the new required code upon the
calls used in place. There is a small race here upon device_release_driver()
but we can live with that theoretical race.
Due to the way we hack this backport we can't use a separate namespace
as we have with other symbols.
mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \
0998d0631001288a5974afc0b2a5f568bcdecb4d
v3.6-rc1~99^2~14^2~17
I count 65 patches implemented after this:
mcgrof@frijol ~/linux-stable (git::master)$ git format-patch \
--grep="device-core: Ensure drvdata = NULL when no driver is bound" \
-o null-drv-fix v3.6-rc1~99^2~14^2~17..
TL;DR
Alan Stern argued that perhaps applying this to backports wasn't a good
idea given that evidence shows that the original patch actually exposed
tons of bugs in driver code where they were doing the wrong thing.
While this may be true if the original patch was a bad idea it should
be reverted, and if a bug is found upstream, then by all means
finding it through backports will only accelerate the pace at which
we fix these exposed bugs. That is, if a bug is found due to this on
backports then a respective fix for it should go upstream, not to
backports. This is the benefit of providing backports releases: keep
your users engaged on upstream fixes.
Furthermore I am in hopes that perhaps we can SmPL'ify the bugs
instead and in the future perhaps require SmPL to proove that
the what the original patch was doing won't affect the inverse
of what the patch was trying to do -- that is drivers doing the
wrong thing.
commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
Author: Hans de Goede
Date: Wed May 23 00:09:34 2012 +0200
device-core: Ensure drvdata = NULL when no driver is bound
1) drvdata is for a driver to store a pointer to driver specific data
2) If no driver is bound, there is no driver specific data associated with
the device
3) Thus logically drvdata should be NULL if no driver is bound.
But many drivers don't clear drvdata on device_release, or set drvdata
early on in probe and leave it set on probe error. Both of which results
in a dangling pointer in drvdata.
This patch enforce for drvdata to be NULL after device_release or on probe
failure.
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
Tested with ckmake against next-20130618:
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31 [ OK ]
9 2.6.32 [ OK ]
10 2.6.33 [ OK ]
11 2.6.34 [ OK ]
12 2.6.35 [ OK ]
13 2.6.36 [ OK ]
14 2.6.37 [ OK ]
15 2.6.38 [ OK ]
16 2.6.39 [ OK ]
17 3.0.79 [ OK ]
18 3.1.10 [ OK ]
19 3.10-rc1[ OK ]
20 3.2.45 [ OK ]
21 3.3.8 [ OK ]
22 3.4.46 [ OK ]
23 3.5.7 [ OK ]
24 3.6.11 [ OK ]
25 3.7.10 [ OK ]
26 3.8.13 [ OK ]
27 3.9.3 [ OK ]
real32m2.332s
user860m23.688s
sys 121m20.840s
Cc: Hans de Goede
Cc: Julia Lawall
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Jiri Slaby
Cc: Jiri Kosina
Cc: Felix Fietkau
Signed-off-by: Luis R. Rodriguez
---
backport/backport-include/linux/device.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/backport/backport-include/linux/device.h
b/backport/backport-include/linux/device.h
index c2f80e2..ba55d0e 100644
--- a/backport/backport-include/linux/device.h
+++ b/backport/backport-include/linux/device.h
@@ -176,4 +176,23 @@ extern int dev_set_name(struct device *dev, const char
*name, ...)
__attribute__((format(printf, 2, 3)));
#endif
+#if LINUX_VERSION_CODE <= KERNEL_VERSION(3,6,0)
+#define driver_probe_device(__drv, __dev) \
+({ \
+ int ret;\
+ ret = (driver_probe_device)(__drv, __dev); \
+ if (ret)\
+ dev_set_drvdata(__dev,
Re: [PATCH] backports: backport drvdata = NULL core driver fixes
On Fri, Jul 19, 2013 at 2:27 PM, Julia Lawall wrote: > On Fri, 19 Jul 2013, Luis R. Rodriguez wrote: > >> On Fri, Jul 19, 2013 at 2:07 PM, Luis R. Rodriguez >> wrote: >> >> This is not a very good idea. Although setting drvdata to NULL allowed >> >> a lot of code to be removed, it also exposed a bunch of hidden bugs -- >> >> drivers were using the drvdata value even after their remove function >> >> returned. >> > >> > Eek, have we not SmPL'ify'd a proof yet to ensure code like this no >> > longer exists? Julia? :) >> >> Come to think of it, perhaps we should require *proof* with SmPL like >> this in future to avoid regressions ? > > Is it a concurrency problem? SmPL is not so good at that in the general > case. One would have to know a specific case where other functions of the > driver can be invoked after remove. Thanks Julia. In that case I'm going to just leave this in place given that if there's a bug upstream we'll get it fixed as soon as a respective patch gets upstream as well. That is, we are not using old drivers, we use the same upstream drivers so if a regression was found in backports the fix must go upstream s well. This is one of the benefits of backporting -- the range of users and testers increases and we still benefit from the upstream bandwagon. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Maybe it's time to shut this thread down (Was: Re: [ 00/19] 3.10.1-stable review)
On Fri, Jul 19, 2013 at 04:03:24PM -0400, Kurt H Maier wrote: > On Fri, Jul 19, 2013 at 12:01:27PM -0700, Sarah Sharp wrote: > > > > I'm not trying to shut down this discussion. But please, let's continue > > this discussion at KS, away from the court of public opinion. I would > > love for this email to serve as a final summary of my opinion. We can > > use this email to start a conversation at KS, and we can argue our > > hearts out there about the various points. > > Well more than half your argument is about how "the court of public > opinion" regards interactions on the mailing list. Why is this > discussion exempt? Come to KS! You're more than welcome to discuss this with us there. With some schedule wrangling, I think we can make the session on LKML communication styles take place on the overlapping day between KS and LinuxCon. That should allow anyone from the wider open source community that wants to participate in this conversation do so. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Fri, 2013-07-19 at 14:22 -0700, Nicholas A. Bellinger wrote: > On Wed, 2013-07-17 at 04:52 +, James Bottomley wrote: > > On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: > > > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: > > > > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > > > > > > > Lets start with discussing this on the list, please, and then see > > > > > where > > > > > we go from there ... > > > > > > > > > > > > > Yes, the discussion is beginning to make it's way to the list. I've > > > > mostly been waiting for blk-mq to get a wider review before taking the > > > > early scsi-mq prototype driver to a larger public audience. > > > > > > > > Primarily, I'm now reaching out to the people most effected by existing > > > > scsi_request_fn() based performance limitations. Most of them have > > > > abandoned existing scsi_request_fn() based logic in favor of raw block > > > > make_request() based drivers, and are now estimating the amount of > > > > effort to move to an scsi-mq based approach. > > > > > > > > Regardless, as the prototype progresses over the next months, having a > > > > face-to-face discussion with the key parties in the room would be very > > > > helpful given the large amount of effort involved to actually make this > > > > type of generational shift in SCSI actually happen. > > > > > > There's a certain amount of overlap with the aio/O_DIRECT work as well. > > > But if it's not a general session, could always be a BOF or something. > > > > > > I'll second the argument that most technical topics probably DO belong > > > in a topic related workshop. But that leaves us with basically only > > > process related topics at KS, I don't think it hurts to have a bit of > > > tech meat on the bone too. At least I personally miss that part of KS > > > from years gone by. > > > > Heh well, given that most of the block mq discussions at LSF have been > > you saying you really should get around to cleaning up and posting the > > code, you'll understand my wanting to see that happen first ... > > > > I suppose we could try to run a storage workshop within KS, but I think > > most of the mini summit slots have already gone. > > That would be great, given there is a reasonable level of interest from > various parities, and the pain threshold for existing scsi small block > random I/O performance is high.. > > When will we know if there is a workshop / mini summit slot available..? > > (CC'ing Mike Christie as well for open-iscsi/scsi-mq bits) > > > There's also plumbers > > if all slots are gone (I would say that, being biased and on the > > programme committee) Ric is running the storage and Filesystems MC > > > > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159 > > FYI, I'm not trying to 'sell' scsi-mq to the larger community yet, but > rather interested in getting the right scsi/block/LLD people in the same > room at KS for an hour or two to discuss implementation details, given > the scope of the effort involved. Well, so that's why I think plumbers might be a better venue: we'll have more of the actual storage people there. Usually we get at most 2-3 storage people to KS compared to the 25 or so we usually have at LSF ... that makes KS not a very good venue for storage centric discussions. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] pci_ids, 8250_pci: remove PCI_VENDOR_ID_ADDIDATA_OLD
On Tue, Jul 16, 2013 at 9:14 AM, Ian Abbott wrote: > The 8250_pci driver uses PCI_VENDOR_ID_ADDIDATA_OLD (0x10e8), > PCI_DEVICE_ID_ADDIDATA_APCI7800 (0x818e) to recognize the original > ADDI-DATA APCI-7800 PCI serial card. However vendor ID 0x10e8 was > assigned by PCI-SIG to Applied Micro Circuits Corporation (AMCC) and the > associated device ID 0x818e was assigned by AMCC to ADDI-DATA. > > Comedi already defines PCI_VENDOR_ID_AMCC as 0x10e8 in one of its header > files, so that definition can be moved into pci_ids.h and the 8250_pci > driver changed to use it. The PCI_DEVICE_ID_ADDIDATA_APCI7800 define > seems out of place in pci_ids.h since it isn't associated with > ADDI-DATA's vendor ID but with AMCC's vendor ID. It's only used in > 8250_pci.c so it can be moved there and renamed to something more > sensible. > > 1) pci_ids.h: move PCI_VENDOR_ID_AMCC here > 2) serial: 8250_pci: replace PCI_VENDOR_ID_ADDIDATA_OLD > 3) serial: 8250_pci: use local device ID for ADDI-DATA APCI-7800 > 4) pci_ids.h: remove PCI_VENDOR_ID_ADDIDATA_OLD and >PCI_DEVICE_ID_ADDIDATA_APCI7800 > > drivers/staging/comedi/comedidev.h | 1 - > drivers/tty/serial/8250/8250_pci.c | 9 + > include/linux/pci_ids.h| 4 ++-- > 3 files changed, 7 insertions(+), 7 deletions(-) For patches 1 & 4 (the ones that touch pci_ids.h): Acked-by: Bjorn Helgaas Please merge them along with the 8250 changes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] backports: backport drvdata = NULL core driver fixes
On Fri, 19 Jul 2013, Luis R. Rodriguez wrote: > On Fri, Jul 19, 2013 at 2:07 PM, Luis R. Rodriguez > wrote: > >> This is not a very good idea. Although setting drvdata to NULL allowed > >> a lot of code to be removed, it also exposed a bunch of hidden bugs -- > >> drivers were using the drvdata value even after their remove function > >> returned. > > > > Eek, have we not SmPL'ify'd a proof yet to ensure code like this no > > longer exists? Julia? :) > > Come to think of it, perhaps we should require *proof* with SmPL like > this in future to avoid regressions ? Is it a concurrency problem? SmPL is not so good at that in the general case. One would have to know a specific case where other functions of the driver can be invoked after remove. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC 1/2] qrwlock: A queue read/write lock implementation
On 07/19/2013 05:11 PM, George Spelvin wrote: What I have in mind is to have 2 separate rwlock initializers - one for fair and one for reader-bias behavior. So the lock owners can decide what behavior do they want with a one line change. That's definitely a nicer patch, if it will work. I was imagining that, even for a single (type of) lock, only a few uses require reader bias (because they might be recursive, or are in an interrupt), but you'd want most read_lock sites to be fair. Yes, fair rwlock will be the default. Deciding on a per-lock basis means that one potentially recursive call means you can't use fair queueing anywhere. I was hoping that the number of necessary unfair calls would be small enough that making the read_lock default fair and only marking the unfair call sites would be enough. But I don't really know until doing a survey of the calls. I think so. The queue read/write lock, if merged, will be an optional feature for people to try out to see if they see any problem in any of the existing rwlock. So far, I didn't encounter any problem in my testing. BTW, I also tried my version of the rwlock without the waiting queue. In high contention case, it performs slightly better than the __read_lock_failed changes suggested by Ingo at least for the reader-bias one. It is still not as good as the full version with the waiting queue. I should be able to provide more performance data next week. Regards, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] RTC: Add an alarm disable quirk
On Fri, Jul 19, 2013 at 05:13:21PM +0200, Borislav Petkov wrote: > Nope, this doesn't help - box just rebooted. :( > > So I'm back to the DMI quirk patch... Ok, some more observations before I throw this box out the window: So, we emulate RTC there with HPET: $ cat /proc/driver/rtc rtc_time: 21:06:48 rtc_date: 2013-07-19 alrm_time : 20:59:59 alrm_date : 2013-07-20 alarm_IRQ : no alrm_pending: no update IRQ enabled : no periodic IRQ enabled: no periodic IRQ frequency : 1024 max user IRQ frequency : 64 24hr: yes periodic_IRQ: no update_IRQ : no HPET_emulated : yes BCD : yes DST_enable : no periodic_freq : 1024 batt_status : okay Now I added a bit debugging printks: [ 11.234652] rtc_cmos_read: addr: 0xb, val: 0x2 [ 11.239960] rtc_cmos_read: addr: 0xc, val: 0x50 [ 11.245360] rtc_cmos_write: addr: 0xb, val: 0x22 This is where we enable the RTC alarm irq. [ 11.250736] rtc_cmos_read: addr: 0xc, val: 0x40 [ 11.256104] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.261458] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.266792] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.272017] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.277307] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.282570] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.287729] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.292957] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.298168] hpet1: lost 1 rtc interrupts And right when we read it out, we get an RTC irq (hpet_rtc_interrupt on comparator 1) and we keep incrementing the comparator until we're ahead of the hpet counter. Normally we'll do it only once and not have lost interrupts but it happens here. And the strange thing is that it happens right after we read RTC_CONTROL, i.e. 0xb, where the alarm irq bit resides. Coincidence...? Hmm, I don't know what to make of it... Anyway, TGIF! Thanks for listening. :) [ 11.302668] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.307852] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.313010] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.318056] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.323164] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.328253] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.333245] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.338319] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.343383] hpet1: lost 1 rtc interrupts [ 11.347753] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.352826] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.357899] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.362858] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.367887] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.372887] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.377797] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.382798] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.387803] hpet1: lost 2 rtc interrupts [ 11.392113] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.397132] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.402143] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.407077] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.412097] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.417116] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.422042] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.427063] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.432085] hpet1: lost 2 rtc interrupts [ 11.436419] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.441455] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.446494] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.451452] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.456500] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.461546] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.466504] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.471551] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.476599] hpet1: lost 2 rtc interrupts [ 11.480958] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.486023] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.491078] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.496047] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.50] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.506172] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.511151] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.516222] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.521289] hpet1: lost 2 rtc interrupts [ 11.525664] rtc_cmos_read: addr: 0xa, val: 0x26 [ 11.530747] rtc_cmos_read: addr: 0x0, val: 0x19 [ 11.535818] rtc_cmos_read: addr: 0x2, val: 0x6 [ 11.540795] rtc_cmos_read: addr: 0x4, val: 0x21 [ 11.545859] rtc_cmos_read: addr: 0x7, val: 0x19 [ 11.550920] rtc_cmos_read: addr: 0x8, val: 0x7 [ 11.555897] rtc_cmos_read: addr: 0x9, val: 0x13 [ 11.560962] rtc_cmos_read: addr: 0xb, val: 0x22 [ 11.566028] hpet1: lost 2 rtc interrupts -- 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
[PATCH] via-rhine: Fix tx_timeout handling
rhine_reset_task() misses to call netif_stop_queue(), this can lead to a crash if work is still scheduled while we're resetting the tx queue. Fixes: [ 93.591707] BUG: unable to handle kernel NULL pointer dereference at 004c [ 93.595514] IP: [] rhine_napipoll+0x491/0x6e Signed-off-by: Richard Weinberger --- drivers/net/ethernet/via/via-rhine.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c index b75eb9e..57e1b40 100644 --- a/drivers/net/ethernet/via/via-rhine.c +++ b/drivers/net/ethernet/via/via-rhine.c @@ -1615,6 +1615,7 @@ static void rhine_reset_task(struct work_struct *work) goto out_unlock; napi_disable(>napi); + netif_stop_queue(dev); spin_lock_bh(>lock); /* clear all descriptors */ -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
On Friday, July 19, 2013 11:08:49 AM Tim Chen wrote: > On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote: > > > > > > This should cause udev to load the crct10dif_pclml module when cpu > > > > > > support the PCLMULQDQ (feature code 0081). I did my testing during > > > > > > development on 3.10 and the module was indeed loaded. > > > > > > > > > > > > However, I found that the following commit under 3.11-rc1 broke > > > > > > the mechanism after some bisection. > > > > > > > > > > > > commit ac212b6980d8d5eda705864fc5a8ecddc6d6eacc > > > > > > Author: Rafael J. Wysocki > > > > > > Date: Fri May 3 00:26:22 2013 +0200 > > > > > > > > > > > > ACPI / processor: Use common hotplug infrastructure > > > > > > > > > > > > Split the ACPI processor driver into two parts, one that is > > > > > > non-modular, resides in the ACPI core and handles the > > > > > > enumeration > > > > > > and hotplug of processors and one that implements the rest of > > > > > > the > > > > > > existing processor driver functionality. > > > > > > > > > > > > Rafael, can you check and see if this can be fixed so those > > > > > > optimized > > > > > > crypto modules for Intel cpu that support them can be loaded? > > > > > > > > > > I think this is an ordering issue between udev startup and the time > > > > > when > > > > > devices are registered. > > > > > > > > Something that can be fixed? > > > > > > I'm sure it can be fixes, but I'm not sure whether it's a udev bug or real > > > breakage in the kernel yet. I need to figure out that part. > > > > OK > > > > I wonder if the appended patch makes the issue go away for you? > > > > Rafael, the patch did fix the cpu feature based module loading issue. > Thanks for your quick response. Alas, this is not the one I'd like to apply. With that patch applied, new device objects are created to avoid binding the processor driver directly to the cpu system device objects, because that apparently confuses udev and it starts to ignore the cpu modalias once the driver has been bound to any of those objects. I've verified in the meantime that this indeed is the case. A link to the patch in question: https://patchwork.kernel.org/patch/2830561/ Greg, I asked you some time ago whether or not it was possible for udev to stop autoloading modules that matched the cpu modalias after a driver had been bound to the cpu system device objects and you said "no". However, this time I can say with certainty that that really is the case. So, the question now is whether or not we can do anything in the kernel to avoid that confusion in udev instead of applying the patch linked above (which is beyond ugly in my not so humble opinion)? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86/pci: checkpatch.pl cleanup
On Wed, Jul 17, 2013 at 1:58 AM, Ingo Molnar wrote: > > * Valentina Manea wrote: > >> This patch fixes warning and errors found by checkpatch.pl: >> >> * replace asm/acpi.h, asm/io.h and asm/smp.h with linux/acpi.h, >> linux/io.h and linux/smp.h respectively >> * remove explicit initialization to 0 of a static global variable >> * replace printk(KERN_INFO ...) with pr_info >> * use tabs instead of spaces for indentation >> * arrange comments so that they adhere to Documentation/CodingStyle >> >> Signed-off-by: Valentina Manea > > Looks good, thanks. > > Bjorn, I can pick this up into tip:x86/cleanups, or would you like to put > this into the PCI tree? I added your ack, capitalized "PCI", "Langwell", etc. consistently, and put it in my pci/misc branch. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] backports: backport drvdata = NULL core driver fixes
On Fri, Jul 19, 2013 at 7:17 AM, Alan Stern wrote: > On Thu, 18 Jul 2013, Luis R. Rodriguez wrote: > >> From: "Luis R. Rodriguez" >> >> The Linux kernel had tons of code which at times cleared the >> drvdata upon probe failure or release. There are however a bunch >> of drivers that didn't clear this. >> >> Commit 0998d063 implmented clearing this upon device_release_driver() >> and dealt with probe failure on driver_probe_device(). After this the >> kernel was cleaned up separately with *tons* of patches to remove all >> these driver specific settings given that the clearing is now done >> internally by the device core. >> >> Instead of ifdef'ing code back in for older code where it was properly >> in place backport this by piggy backing the new required code upon the >> calls used in place. There is a small race here upon device_release_driver() >> but we can live with that theoretical race. >> >> Due to the way we hack this backport we can't use a separate namespace >> as we have with other symbols. >> >> mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \ >> 0998d0631001288a5974afc0b2a5f568bcdecb4d >> v3.6-rc1~99^2~14^2~17 >> >> commit 0998d0631001288a5974afc0b2a5f568bcdecb4d >> Author: Hans de Goede >> Date: Wed May 23 00:09:34 2012 +0200 >> >> device-core: Ensure drvdata = NULL when no driver is bound >> >> 1) drvdata is for a driver to store a pointer to driver specific data >> 2) If no driver is bound, there is no driver specific data associated >> with >>the device >> 3) Thus logically drvdata should be NULL if no driver is bound. >> >> But many drivers don't clear drvdata on device_release, or set drvdata >> early on in probe and leave it set on probe error. Both of which results >> in a dangling pointer in drvdata. >> >> This patch enforce for drvdata to be NULL after device_release or on >> probe >> failure. >> >> Signed-off-by: Hans de Goede >> Signed-off-by: Greg Kroah-Hartman > > This is not a very good idea. Although setting drvdata to NULL allowed > a lot of code to be removed, it also exposed a bunch of hidden bugs -- > drivers were using the drvdata value even after their remove function > returned. Eek, have we not SmPL'ify'd a proof yet to ensure code like this no longer exists? Julia? :) > Several commits have been applied to fix those bugs. I actualy found *tons* ! > Finding and backporting them and their dependencies will not be easy. May the SmPL proof be with us. > I suggest this patch not be applied. Thanks for the review Alan! Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC 1/2] qrwlock: A queue read/write lock implementation
> What I have in mind is to have 2 separate rwlock initializers - one for > fair and one for reader-bias behavior. So the lock owners can decide > what behavior do they want with a one line change. That's definitely a nicer patch, if it will work. I was imagining that, even for a single (type of) lock, only a few uses require reader bias (because they might be recursive, or are in an interrupt), but you'd want most read_lock sites to be fair. Deciding on a per-lock basis means that one potentially recursive call means you can't use fair queueing anywhere. I was hoping that the number of necessary unfair calls would be small enough that making the read_lock default fair and only marking the unfair call sites would be enough. But I don't really know until doing a survey of the calls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: properly handle KVM emulation of hyperv
On 07/19/2013 02:00 PM, Paolo Bonzini wrote:
> Il 19/07/2013 22:59, H. Peter Anvin ha scritto:
>> -cpuid(KVM_CPUID_SIGNATURE, , , , );
>> -memcpy(signature + 0, , 4);
>> -memcpy(signature + 4, , 4);
>> -memcpy(signature + 8, , 4);
>> -signature[12] = 0;
>> -
>> -if (strcmp(signature, "KVMKVMKVM") == 0)
>> +if (kvm_para_available_function(KVM_CPUID_SIGNATURE) ||
>> +
>> kvm_para_available_function(KVM_CPUID_SIGNATURE_NEXT))
>> return true;
>> }
Nice catch. Just one small thing, you should loop until 0x4001, as
done in arch/x86/include/asm/xen/hypervisor.h, in case one day a third
hypervisor implements three extensions (Hyper-V, KVM and its own set).
>> Any way we can centralize this stuff?
>
> I guess a function cpuid_hypervisor_base("KVMKVMKVM") that does the scan?
>
Something like that.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: core: Avoid double minus in sysfs output
On 07/19/2013 07:15 AM, Oleksandr Kravchenko wrote: > On Thu, Jul 18, 2013 at 7:24 PM, Lars-Peter Clausen wrote: >> On 07/18/2013 05:47 PM, Oleksandr Kravchenko wrote: >>> From: Oleksandr Kravchenko >>> >>> This patch fixes the issue with double minus in output when >>> reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and >>> IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 >>> both are negatives output string contains "--" before >>> digits. It is result of "-%d..." in sprintf() format. >>> >> >> Hm, this might be a bug in a driver that is triggering this. The idea is >> that val2 is only allowed to be negative if val is 0. >> >> - Lars >> > If I calculate val and val2 in next way: > *val = adc / 100; > *val2 = adc % 100; > both val and val2 could by negative. Do I have to check it in my driver? > I guess it is will happen occasionally. In the c89 standard, module for a negative is implementation specific. Anyone know if we can assume this will work in all cases within the kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
