linux.kernel - 26 new messages in 17 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* serial: samsung: Move uart_register_driver call to device probe - 4 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
* zram: introduce zram compressor operations struct - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/92f95a6da293588e?hl=en
* xen-netback: Timeout packets in RX path - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fa3947f0129612f2?hl=en
* module: Add missing newline in printk call. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ed63f691feeb5c5b?hl=en
* Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67e8c4b6b26e9de1?hl=en
* [V2] MAINTAINERS: Add dts files for r8 series to SHMOBILE - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/96064e68a80c8477?hl=en
* Dirty deleted files cause pointless I/O storms (unless truncated first) - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f7a8acf8a633dc13?hl=en
* MCS Lock: Restructure the MCS lock defines and locking - 7 messages, 1
author
http://groups.google.com/group/linux.kernel/t/559403da76947798?hl=en
* ALSA: hda - Fix possible races in HDMI driver - lockup on shutdown when
radeon.audio=1 after using audacity - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c536814557a902d9?hl=en
* : Is using CPU hotplug right for isolating CPUs? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b8316d08999429a4?hl=en
* Backlight driver for MacBook Air 6,1 and 6,2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/46cdf53a3fcbe1e9?hl=en
* 3.12.6-rt9 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d02cbc395b01f73b?hl=en
* math_state_restore and kernel_fpu_end disable interrupts? - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/4f2afb452e630694?hl=en
* i2c: New bus driver for the QUP I2C controller - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2c6bb71246961625?hl=en
* mm/zswap: Check all pool pages instead of one pool pages - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/81cd07f00a212f3a?hl=en
* ACPI: Fix acpi_evaluate_object() return value check - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/562e28ed7fc5ad66?hl=en
* linux-next: manual merge of the sound-asoc tree with the tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/1cb34df4a23eaf18?hl=en

==============================================================================
TOPIC: serial: samsung: Move uart_register_driver call to device probe
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Jan 20 2014 4:10 pm
From: Russell King - ARM Linux


On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote:
> > I don't believe the driver model has any locking to prevent a drivers
> > ->probe function running concurrently with it's ->remove function for
> > two (or more) devices.
>
> The bus prevents this from happening.
>
> > The locking against this is done on a per-device basis, not a per-driver
> > basis.
>
> No, on a per-bus basis.

I don't see it.

Let's start from driver_register().
This takes no locks and calls bus_add_driver().
This also takes no locks and calls driver_attach().
This walks the list of devices calling __driver_attach() for each.
__driver_attach() tries to match the device against the driver,
locks the parent device if one exists, and the device which is about
to be probed. It then calls driver_probe_device().
driver_probe_device() inserts a runtime barrier and calls really_probe().
really_probe() ultimately calls either the bus ->probe method or the
driver ->probe method.

At no point in that sequence do I see anything which does any locking
on a per-driver basis. Let's look at device_add().

device_add() calls bus_probe_device(), which then calls device_attach().
device_attach() takes the device's lock, and walks the list of drivers
calling __device_attach() on each driver. This then calls down into
driver_probe_device(), and the path is the same as the above.

I don't see any per-driver locking here either.

I've checked the klist stuff, don't see anything there. Ditto for
bus_for_each_drv().

If you think there's a per-driver lock that's held over probes or removes,
please point it out. I'm fairly certain that there isn't, because we have
to be able to deal with recursive probes (yes, we've had to deal with
those in the past.)

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Mon, Jan 20 2014 4:20 pm
From: Russell King - ARM Linux


On Mon, Jan 20, 2014 at 11:47:34PM +0000, Alan Cox wrote:
> But yes I agree about the idiom, but a definite NAK to any attempts to
> plaster over this grand screwup by crapping in the tty core. Your turd,
> deal with it locally in the ARM code if you can't apply common sense and
> just go dynamic.

I believe at the time there was no one maintaining the device list to
_do_ that allocation - AMBA PL011 came along in 2005 after (I believe)
hpa stopped looking after that list.

So, please tell me how a number could be allocated properly without the
device numbers list being maintained?

I've no problem with going dynamic, and I suggest that you get a sense
of perspective rather than just spouting rubbish from on high.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 4 ==
Date: Mon, Jan 20 2014 4:30 pm
From: Greg KH


On Tue, Jan 21, 2014 at 12:07:06AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote:
> > > I don't believe the driver model has any locking to prevent a drivers
> > > ->probe function running concurrently with it's ->remove function for
> > > two (or more) devices.
> >
> > The bus prevents this from happening.
> >
> > > The locking against this is done on a per-device basis, not a per-driver
> > > basis.
> >
> > No, on a per-bus basis.
>
> I don't see it.
>
> Let's start from driver_register().

Which happens from module probing, which is single-threaded, right?

Or from module_init callbacks, which is single-threaded.

Normally, busses never add devices (which is what drivers bind to),
except in a single-at-a-time fashion, unless they really know what they
are doing (i.e. PCI had multi-threaded device probing for a while, don't
remember if it still does...)


> This takes no locks and calls bus_add_driver().
> This also takes no locks and calls driver_attach().
> This walks the list of devices calling __driver_attach() for each.
> __driver_attach() tries to match the device against the driver,
> locks the parent device if one exists, and the device which is about
> to be probed. It then calls driver_probe_device().
> driver_probe_device() inserts a runtime barrier and calls really_probe().
> really_probe() ultimately calls either the bus ->probe method or the
> driver ->probe method.
>
> At no point in that sequence do I see anything which does any locking
> on a per-driver basis. Let's look at device_add().
>
> device_add() calls bus_probe_device(), which then calls device_attach().
> device_attach() takes the device's lock, and walks the list of drivers
> calling __device_attach() on each driver. This then calls down into
> driver_probe_device(), and the path is the same as the above.
>
> I don't see any per-driver locking here either.
>
> I've checked the klist stuff, don't see anything there. Ditto for
> bus_for_each_drv().
>
> If you think there's a per-driver lock that's held over probes or removes,
> please point it out. I'm fairly certain that there isn't, because we have
> to be able to deal with recursive probes (yes, we've had to deal with
> those in the past.)

Hm, you are right, I think that's why we had to remove the locks. The
klist stuff handles us getting the needed locks for managing our
internal lists of devices and drivers, and those should be fine.

So, let's go back to your original worry, what are you concerned about?
A device being removed while probe() is called?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Mon, Jan 20 2014 4:40 pm
From: Russell King - ARM Linux


On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
> On Tue, Jan 21, 2014 at 12:07:06AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > > On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote:
> > > > I don't believe the driver model has any locking to prevent a drivers
> > > > ->probe function running concurrently with it's ->remove function for
> > > > two (or more) devices.
> > >
> > > The bus prevents this from happening.
> > >
> > > > The locking against this is done on a per-device basis, not a per-driver
> > > > basis.
> > >
> > > No, on a per-bus basis.
> >
> > I don't see it.
> >
> > Let's start from driver_register().
>
> Which happens from module probing, which is single-threaded, right?

Yes, to _some_ extent - the driver is added to the bus list of drivers
before existing drivers are probed, so it's always worth bearing in
mind that if a new device comes along, it's possible for that device
to be offered to even a driver which hasn't finished returning from
its module_init().

> > If you think there's a per-driver lock that's held over probes or removes,
> > please point it out. I'm fairly certain that there isn't, because we have
> > to be able to deal with recursive probes (yes, we've had to deal with
> > those in the past.)
>
> Hm, you are right, I think that's why we had to remove the locks. The
> klist stuff handles us getting the needed locks for managing our
> internal lists of devices and drivers, and those should be fine.
>
> So, let's go back to your original worry, what are you concerned about?
> A device being removed while probe() is called?

My concern is that we're turning something which should be simple into
something unnecessarily complex. By that, I mean something along the
lines of:

static DEFINE_MUTEX(foo_mutex);
static unsigned foo_devices;

static int foo_probe(struct platform_device *pdev)
{
int ret;

mutex_lock(&foo_mutex);
if (foo_devices++ == 0)
uart_register_driver(&driver);

ret = foo_really_probe_device(pdev);
if (ret) {
if (--foo_devices == 0)
uart_unregister_driver(&driver);
}
mutex_unlock(&foo_mutex);

return ret;
}

static int foo_remove(struct platform_device *pdev)
{
mutex_lock(&foo_mutex);
foo_really_remove(pdev);
if (--foo_devices == 0)
uart_unregister_driver(&driver);
mutex_unlock(&foo_mutex);

return 0;
}

in every single serial driver we have... Wouldn't it just be better to
fix the major/minor number problem rather than have to add all that code
repetitively to all those drivers?

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: zram: introduce zram compressor operations struct
http://groups.google.com/group/linux.kernel/t/92f95a6da293588e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 4:10 pm
From: Minchan Kim


On Mon, Jan 20, 2014 at 01:03:48PM +0300, Sergey Senozhatsky wrote:
> On (01/20/14 14:12), Minchan Kim wrote:
> > Hello Sergey,
> >
> > I reviewed this patchset and I suggest somethings.
> > Please have a look and feedback to me. :)
> >
> > 1. Let's define new file zram_comp.c
> > 2. zram_comp includes following field
> > .create
> > .compress
> > .decompress.
> > .destroy
> > .name
> >
>
> alternatively, we can use crypto api, the same way as zswap does (that
> will require handling of cpu hotplug).
>
> -ss

I really doubt what's the benefit from crypto API for zram.
It's maybe since I'm not familiar with it so I should ask a silly
question.

1. What's the runtime overhead for using such frontend?

As you know, zram is in-memory block device so I don't want to
add unnecessary overhead to optimize.

2. What's the memory footprint for using such frontend?

As you know, zram is very popular for small-memory embedded device
so I don't want to consume more runtime memory and static memory
due to CONFIG_CRYPTO friend.

3. Is it a flexible to alloc/handle multiple compressor buffer for
the our purpose? zswap and zcache have been used it with per-cpu
buffer but it would a problem for write scalabitliy if we uses zlib
which takes long time to compress.
When I read code, maybe we can allocate multiple buffers through
cryptop_alloc_compo several time but it would cause 1) and 2) problem
again.

So, what's the attractive point for using crypto?
One of thing I could imagine is that it could make zram H/W compressor
but I don't have heard about it so if we don't have any special reason,
I'd like to go with raw compressor so we can get a *base* number. Then,
if we really need crypto API, we can change it easily and benchmark.
Finally, we could get a comparision number in future and it would make
the decision easily.

Thanks.

--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: xen-netback: Timeout packets in RX path
http://groups.google.com/group/linux.kernel/t/fa3947f0129612f2?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 4:30 pm
From: Zoltan Kiss


On 20/01/14 22:03, Wei Liu wrote:
> On Mon, Jan 20, 2014 at 09:24:28PM +0000, Zoltan Kiss wrote:
>> @@ -557,12 +577,25 @@ void xenvif_disconnect(struct xenvif *vif)
>> void xenvif_free(struct xenvif *vif)
>> {
>> int i, unmap_timeout = 0;
>> + /* Here we want to avoid timeout messages if an skb can be legitimatly
>> + * stucked somewhere else. Realisticly this could be an another vif's
>> + * internal or QDisc queue. That another vif also has this
>> + * rx_drain_timeout_msecs timeout, but the timer only ditches the
>> + * internal queue. After that, the QDisc queue can put in worst case
>> + * XEN_NETIF_RX_RING_SIZE / MAX_SKB_FRAGS skbs into that another vif's
>> + * internal queue, so we need several rounds of such timeouts until we
>> + * can be sure that no another vif should have skb's from us. We are
>> + * not sending more skb's, so newly stucked packets are not interesting
>> + * for us here.
>> + */
> You beat me to this. Was about to reply to your other email. :-)
>
> It's also worth mentioning that DIV_ROUND_UP part is merely estimation,
> as you cannot possible know the maximum / miminum queue length of all
> other vifs (as they can be changed during runtime). In practice most
> users will stick with the default, but some advanced users might want to
> tune this value for individual vif (whether that's a good idea or not is
> another topic).
>
> So, in order to convince myself this is safe. I also did some analysis
> on the impact of having queue length other than default value. If
> queue_len < XENVIF_QUEUE_LENGTH, that means you can queue less packets
> in qdisc than default and drain it faster than calculated, which is
> safe. On the other hand if queue_len > XENVIF_QUEUE_LENGTH, it means
> actually you need more time than calculated. I'm in two minded here. The
> default value seems sensible to me but I'm still a bit worried about the
> queue_len > XENVIF_QUEUE_LENGTH case.
>
> An idea is to book-keep maximum tx queue len among all vifs and use that
> to calculate worst scenario.
I don't think it should be that perfect. This is just a best effort
estimation, if someone changes the vif queue length and see this message
because of that, nothing very drastic will happen. It is just a rate
limited warning message. Well, it is marked as error, because it is a
serious condition.
And also, the odds of seeing this message unnecessarily are quite low.
With default settings (256 slots, max 17 per skb, 32 queue length, 10
secs queue drain timeout) this delay is 20 seconds. You can raise the
queue length to 64 before getting warning (see netif_napi_add), so it
would go up to 40 seconds, but anyway, if your vif is sitting on a
packet more than 20 seconds, you deserve this message :)

Zoli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: module: Add missing newline in printk call.
http://groups.google.com/group/linux.kernel/t/ed63f691feeb5c5b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 4:40 pm
From: Rusty Russell


Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> Rusty, would you pick up this patch?
>
> This message was added in 3.13-rc1. Thus, should be fixed in 3.13.

Thanks, applied. It's a bit trivial for a CC:stable though.

Cheers,
Rusty.

> Tetsuo Handa wrote:
>> From cc90e27d5cda227e7a0cbeb5de3cc1cbb1595dfa Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> Date: Mon, 23 Dec 2013 15:52:42 +0900
>> Subject: [PATCH] module: Add missing newline in printk call.
>>
>> Add missing \n and also follow commit bddb12b3 "kernel/module.c: use pr_foo()".
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> ---
>> kernel/module.c | 6 ++----
>> 1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index f5a3b1e..d24fcf2 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -815,10 +815,8 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
>> return -EFAULT;
>> name[MODULE_NAME_LEN-1] = '\0';
>>
>> - if (!(flags & O_NONBLOCK)) {
>> - printk(KERN_WARNING
>> - "waiting module removal not supported: please upgrade");
>> - }
>> + if (!(flags & O_NONBLOCK))
>> + pr_warn("waiting module removal not supported: please upgrade\n");
>>
>> if (mutex_lock_interruptible(&module_mutex) != 0)
>> return -EINTR;
>> --
>> 1.7.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix
bug
http://groups.google.com/group/linux.kernel/t/67e8c4b6b26e9de1?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 4:50 pm
From: Reyad Attiyat


The below patch fixes a bug 64811
(https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
Surface Type/Touch cover 2 devices being detected as a multitouch
device.
The fix adds the HID of the two devices to hid-microsoft driver. This
ensures that hid-input will eventually be used for the device and not
hid-multitouch.

From 866c814f3f6740a5a79858fdf8bf5bbcdc3b57f8 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <reyad.attiyat@gmail.com>
Date: Mon, 20 Jan 2014 16:24:49 -0600
Subject: [PATCH 1/2] Added in ID's for Surface Type/Touch cover 2 to the
hid-microsoft driver

---
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201

diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },

{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: [V2] MAINTAINERS: Add dts files for r8 series to SHMOBILE
http://groups.google.com/group/linux.kernel/t/96064e68a80c8477?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 5:00 pm
From: Simon Horman


Hi Ben,

thanks for your work on this.

On Mon, Jan 20, 2014 at 04:10:32PM +0000, Ben Dooks wrote:
> Add a number of files to the list of files covered by SHMOBILE
> so any changes to these can be reported with get_maintailers.pl
> for the current SHMOILE architectures.

I'm fine with you only addressing r8 and r7 SoCs, I am happy
to make an incremental patch to cover the stragglers (sh7*, emev2).
And I would be even happier if this patch didn't suffer excessive
bike-shedding. But I think there are some minor inconsistencies in this
patch.

Firstly, I think the subject should probably mention r7 and defconfigs.

>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> v2:
> - add defconfigs and r7 configurations
> - fix path to dt-bindings
>
> Cc: Joe Perches <joe@perches.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6c20792..f74d830 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1239,7 +1239,14 @@ Q: http://patchwork.kernel.org/project/linux-sh/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
> S: Supported
> F: arch/arm/mach-shmobile/
> +F: arch/arm/boot/dts/r8*
> +F: arch/arm/boot/dts/r7*
> +F: arch/arm/configs/bockw_defconfig
> +F: arch/arm/configs/genmai_defconfig
> +F: arch/arm/configs/lager_defconfig
> +F: arch/arm/configs/marzen_defconfig

I believe you should ad the following as they are for boards
that use SoCs whose name matches r8*.

arch/arm/configs/armadillo800eva_defconfig
arch/arm/configs/ape6evm_defconfig
arch/arm/configs/koelsch_defconfig

> F: drivers/sh/
> +F: include/dt-bindings/clock/r8a*
>
> ARM/SOCFPGA ARCHITECTURE
> M: Dinh Nguyen <dinguyen@altera.com>
> --
> 1.8.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: Dirty deleted files cause pointless I/O storms (unless truncated first)
http://groups.google.com/group/linux.kernel/t/f7a8acf8a633dc13?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 5:10 pm
From: Andy Lutomirski


The code below runs quickly for a few iterations, and then it slows
down and the whole system becomes laggy for far too long.

Removing the sync_file_range call results in no I/O being performed at
all (which means that the kernel isn't totally screwing this up), and
changing "4096" to SIZE causes lots of I/O but without
the going-out-to-lunch bit (unsurprisingly).

Surprisingly, uncommenting the ftruncate call seems to fix the
problem. This suggests that all the necessary infrastructure to avoid
wasting time writing to deleted files is there but that it's not
getting used.


#define _GNU_SOURCE
#include <sys/mman.h>
#include <err.h>
#include <fcntl.h>
#include <stdbool.h>
#include <stdio.h>
#include <string.h>

#define SIZE (16 * 1048576)

static void hammer(const char *name)
{
int fd = open(name, O_RDWR | O_CREAT | O_EXCL, 0600);
if (fd == -1)
err(1, "open");

fallocate(fd, 0, 0, SIZE);

void *addr = mmap(NULL, SIZE, PROT_WRITE, MAP_SHARED, fd, 0);
if (addr == MAP_FAILED)
err(1, "mmap");

memset(addr, 0, SIZE);

if (munmap(addr, SIZE) != 0)
err(1, "munmap");

if (sync_file_range(fd, 0, 4096,
SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE |
SYNC_FILE_RANGE_WAIT_AFTER) != 0)
err(1, "sync_file_range");

if (unlink(name) != 0)
err(1, "unlink");

// if (ftruncate(fd, 0) != 0)
// err(1, "ftruncate");

close(fd);
}

int main(int argc, char **argv)
{
if (argc != 2) {
printf("Usage: hammer_and_delete FILENAME\n");
return 1;
}

while (true) {
hammer(argv[1]);
write(1, ".", 1);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: MCS Lock: Restructure the MCS lock defines and locking
http://groups.google.com/group/linux.kernel/t/559403da76947798?hl=en
==============================================================================

== 1 of 7 ==
Date: Mon, Jan 20 2014 5:30 pm
From: Tim Chen


We will need the MCS lock code for doing optimistic spinning for rwsem
and queue rwlock. Extracting the MCS code from mutex.c and put into
its own file allow us to reuse this code easily.

Note that using the smp_load_acquire/smp_store_release pair used in
mcs_lock and mcs_unlock is not sufficient to form a full memory barrier
across cpus for many architectures (except x86). For applications that
absolutely need a full barrier across multiple cpus with mcs_unlock and
mcs_lock pair, smp_mb__after_unlock_lock() should be used after mcs_lock.

Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
---
include/linux/mcs_spinlock.h | 81 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/mutex.h | 5 +--
kernel/locking/mutex.c | 68 ++++---------------------------------
3 files changed, 91 insertions(+), 63 deletions(-)
create mode 100644 include/linux/mcs_spinlock.h

diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h
new file mode 100644
index 0000000..23912cb
--- /dev/null
+++ b/include/linux/mcs_spinlock.h
@@ -0,0 +1,81 @@
+/*
+ * MCS lock defines
+ *
+ * This file contains the main data structure and API definitions of MCS lock.
+ *
+ * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock
+ * with the desirable properties of being fair, and with each cpu trying
+ * to acquire the lock spinning on a local variable.
+ * It avoids expensive cache bouncings that common test-and-set spin-lock
+ * implementations incur.
+ */
+#ifndef __LINUX_MCS_SPINLOCK_H
+#define __LINUX_MCS_SPINLOCK_H
+
+struct mcs_spinlock {
+ struct mcs_spinlock *next;
+ int locked; /* 1 if lock acquired */
+};
+
+/*
+ * Note: the smp_load_acquire/smp_store_release pair is not
+ * sufficient to form a full memory barrier across
+ * cpus for many architectures (except x86) for mcs_unlock and mcs_lock.
+ * For applications that need a full barrier across multiple cpus
+ * with mcs_unlock and mcs_lock pair, smp_mb__after_unlock_lock() should be
+ * used after mcs_lock.
+ */
+
+/*
+ * We don't inline mcs_spin_lock() so that perf can correctly account for the
+ * time spent in this lock function.
+ */
+static noinline
+void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
+{
+ struct mcs_spinlock *prev;
+
+ /* Init node */
+ node->locked = 0;
+ node->next = NULL;
+
+ prev = xchg(lock, node);
+ if (likely(prev == NULL)) {
+ /* Lock acquired */
+ node->locked = 1;
+ return;
+ }
+ ACCESS_ONCE(prev->next) = node;
+ /*
+ * Wait until the lock holder passes the lock down.
+ * Using smp_load_acquire() provides a memory barrier that
+ * ensures subsequent operations happen after the lock is acquired.
+ */
+ while (!(smp_load_acquire(&node->locked)))
+ arch_mutex_cpu_relax();
+}
+
+static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
+{
+ struct mcs_spinlock *next = ACCESS_ONCE(node->next);
+
+ if (likely(!next)) {
+ /*
+ * Release the lock by setting it to NULL
+ */
+ if (cmpxchg(lock, node, NULL) == node)
+ return;
+ /* Wait until the next pointer is set */
+ while (!(next = ACCESS_ONCE(node->next)))
+ arch_mutex_cpu_relax();
+ }
+ /*
+ * Pass lock to next waiter.
+ * smp_store_release() provides a memory barrier to ensure
+ * all operations in the critical section has been completed
+ * before unlocking.
+ */
+ smp_store_release(&next->locked, 1);
+}
+
+