* [PATCH 31/36] Staging: cx25821: cx25821-video.c: Fix assignment
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Change double assignment in one statement into two assignment
statements.
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821-video.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video.c b/drivers/staging/cx25821/cx25821-video.c
index 268fe19..b07c3a8 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -1622,7 +1622,8 @@ int cx25821_vidioc_cropcap(struct file *file, void *priv,
if (cropcap->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
- cropcap->bounds.top = cropcap->bounds.left = 0;
+ cropcap->bounds.top = 0;
+ cropcap->bounds.left = 0;
cropcap->bounds.width = 720;
cropcap->bounds.height = dev->tvnorm == V4L2_STD_PAL_BG ? 576 : 480;
cropcap->pixelaspect.numerator =
--
1.7.0.4
^ permalink raw reply related
* [PATCH 32/36] Staging: cx25821: cx25821-video.c: Fix definitions
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Change multiple definitions in one statement into multiple statements
with one definition per statement.
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821-video.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video.c b/drivers/staging/cx25821/cx25821-video.c
index b07c3a8..0ba4f43 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -1829,8 +1829,11 @@ static long video_ioctl_set(struct file *file, unsigned int cmd,
struct downstream_user_struct *data_from_user;
int command;
int width = 720;
- int selected_channel = 0, pix_format = 0, i = 0;
- int cif_enable = 0, cif_width = 0;
+ int selected_channel = 0;
+ int pix_format = 0;
+ int i = 0;
+ int cif_enable = 0;
+ int cif_width = 0;
u32 value = 0;
data_from_user = (struct downstream_user_struct *)arg;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 33/36] Staging: cx25821: cx25821-video.c: Move operators
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Move operator in complex expression to the end of the line to preserve
consistency.
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821-video.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video.c b/drivers/staging/cx25821/cx25821-video.c
index 0ba4f43..1f9309b 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -616,8 +616,8 @@ int cx25821_buffer_prepare(struct videobuf_queue *q, struct videobuf_buffer *vb,
if (channel_opened >= 0 && channel_opened <= 7) {
if (dev->channels[channel_opened]
.use_cif_resolution) {
- if (dev->tvnorm & V4L2_STD_PAL_BG
- || dev->tvnorm & V4L2_STD_PAL_DK)
+ if (dev->tvnorm & V4L2_STD_PAL_BG ||
+ dev->tvnorm & V4L2_STD_PAL_DK)
bpl_local = 352 << 1;
else
bpl_local =
--
1.7.0.4
^ permalink raw reply related
* [PATCH 34/36] Staging: cx25821: cx25821-video.c: Fix indent
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Fix indent of statements to improve readability.
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821-video.c | 79 +++++++++++++++----------------
1 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video.c b/drivers/staging/cx25821/cx25821-video.c
index 1f9309b..bc6af41 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -118,12 +118,12 @@ void cx25821_dump_video_queue(struct cx25821_dev *dev,
if (!list_empty(&q->active)) {
list_for_each(item, &q->active)
- buf = list_entry(item, struct cx25821_buffer, vb.queue);
+ buf = list_entry(item, struct cx25821_buffer, vb.queue);
}
if (!list_empty(&q->queued)) {
list_for_each(item, &q->queued)
- buf = list_entry(item, struct cx25821_buffer, vb.queue);
+ buf = list_entry(item, struct cx25821_buffer, vb.queue);
}
}
@@ -484,8 +484,7 @@ int cx25821_video_register(struct cx25821_dev *dev)
cx25821_init_controls(dev, i);
cx25821_risc_stopper(dev->pci, &dev->channels[i].vidq.stopper,
- dev->channels[i].sram_channels->dma_ctl,
- 0x11, 0);
+ dev->channels[i].sram_channels->dma_ctl, 0x11, 0);
dev->channels[i].sram_channels = &cx25821_sram_channels[i];
dev->channels[i].video_dev = NULL;
@@ -557,7 +556,7 @@ int cx25821_buffer_prepare(struct videobuf_queue *q, struct videobuf_buffer *vb,
struct cx25821_fh *fh = q->priv_data;
struct cx25821_dev *dev = fh->dev;
struct cx25821_buffer *buf =
- container_of(vb, struct cx25821_buffer, vb);
+ container_of(vb, struct cx25821_buffer, vb);
int rc, init_buffer = 0;
u32 line0_offset, line1_offset;
struct videobuf_dmabuf *dma = videobuf_to_dma(&buf->vb);
@@ -684,7 +683,7 @@ void cx25821_buffer_release(struct videobuf_queue *q,
struct videobuf_buffer *vb)
{
struct cx25821_buffer *buf =
- container_of(vb, struct cx25821_buffer, vb);
+ container_of(vb, struct cx25821_buffer, vb);
cx25821_free_buffer(q, buf);
}
@@ -722,7 +721,7 @@ int cx25821_video_mmap(struct file *file, struct vm_area_struct *vma)
static void buffer_queue(struct videobuf_queue *vq, struct videobuf_buffer *vb)
{
struct cx25821_buffer *buf =
- container_of(vb, struct cx25821_buffer, vb);
+ container_of(vb, struct cx25821_buffer, vb);
struct cx25821_buffer *prev;
struct cx25821_fh *fh = vq->priv_data;
struct cx25821_dev *dev = fh->dev;
@@ -813,7 +812,7 @@ static int video_open(struct file *file)
for (i = 0; i < MAX_VID_CHANNEL_NUM; i++) {
if (h->channels[i].video_dev &&
- h->channels[i].video_dev->minor == minor) {
+ h->channels[i].video_dev->minor == minor) {
dev = h;
ch_id = i;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
@@ -1453,38 +1452,38 @@ static const struct v4l2_queryctrl no_ctl = {
static struct v4l2_queryctrl cx25821_ctls[] = {
/* --- video --- */
{
- .id = V4L2_CID_BRIGHTNESS,
- .name = "Brightness",
- .minimum = 0,
- .maximum = 10000,
- .step = 1,
- .default_value = 6200,
- .type = V4L2_CTRL_TYPE_INTEGER,
- }, {
- .id = V4L2_CID_CONTRAST,
- .name = "Contrast",
- .minimum = 0,
- .maximum = 10000,
- .step = 1,
- .default_value = 5000,
- .type = V4L2_CTRL_TYPE_INTEGER,
- }, {
- .id = V4L2_CID_SATURATION,
- .name = "Saturation",
- .minimum = 0,
- .maximum = 10000,
- .step = 1,
- .default_value = 5000,
- .type = V4L2_CTRL_TYPE_INTEGER,
- }, {
- .id = V4L2_CID_HUE,
- .name = "Hue",
- .minimum = 0,
- .maximum = 10000,
- .step = 1,
- .default_value = 5000,
- .type = V4L2_CTRL_TYPE_INTEGER,
- }
+ .id = V4L2_CID_BRIGHTNESS,
+ .name = "Brightness",
+ .minimum = 0,
+ .maximum = 10000,
+ .step = 1,
+ .default_value = 6200,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ }, {
+ .id = V4L2_CID_CONTRAST,
+ .name = "Contrast",
+ .minimum = 0,
+ .maximum = 10000,
+ .step = 1,
+ .default_value = 5000,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ }, {
+ .id = V4L2_CID_SATURATION,
+ .name = "Saturation",
+ .minimum = 0,
+ .maximum = 10000,
+ .step = 1,
+ .default_value = 5000,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ }, {
+ .id = V4L2_CID_HUE,
+ .name = "Hue",
+ .minimum = 0,
+ .maximum = 10000,
+ .step = 1,
+ .default_value = 5000,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ }
};
static const int CX25821_CTLS = ARRAY_SIZE(cx25821_ctls);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 35/36] Staging: cx25821: cx25821-video.c: Change line endings
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Change obscure line endings to less obscure ones. (improve readability)
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821-video.c | 47 ++++++++++++++----------------
1 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video.c b/drivers/staging/cx25821/cx25821-video.c
index bc6af41..e9dd999 100644
--- a/drivers/staging/cx25821/cx25821-video.c
+++ b/drivers/staging/cx25821/cx25821-video.c
@@ -140,8 +140,8 @@ void cx25821_video_wakeup(struct cx25821_dev *dev, struct cx25821_dmaqueue *q,
break;
}
- buf =
- list_entry(q->active.next, struct cx25821_buffer, vb.queue);
+ buf = list_entry(q->active.next, struct cx25821_buffer,
+ vb.queue);
/* count comes from the hw and it is 16bit wide --
* this trick handles wrap-arounds correctly for
@@ -318,8 +318,8 @@ int cx25821_restart_video_queue(struct cx25821_dev *dev,
struct list_head *item;
if (!list_empty(&q->active)) {
- buf =
- list_entry(q->active.next, struct cx25821_buffer, vb.queue);
+ buf = list_entry(q->active.next, struct cx25821_buffer,
+ vb.queue);
cx25821_start_video_dma(dev, q, buf, channel);
@@ -337,8 +337,8 @@ int cx25821_restart_video_queue(struct cx25821_dev *dev,
if (list_empty(&q->queued))
return 0;
- buf =
- list_entry(q->queued.next, struct cx25821_buffer, vb.queue);
+ buf = list_entry(q->queued.next, struct cx25821_buffer,
+ vb.queue);
if (NULL == prev) {
list_move_tail(&buf->vb.queue, &q->active);
@@ -375,8 +375,8 @@ void cx25821_vid_timeout(unsigned long data)
spin_lock_irqsave(&dev->slock, flags);
while (!list_empty(&q->active)) {
- buf =
- list_entry(q->active.next, struct cx25821_buffer, vb.queue);
+ buf = list_entry(q->active.next, struct cx25821_buffer,
+ vb.queue);
list_del(&buf->vb.queue);
buf->vb.state = VIDEOBUF_ERROR;
@@ -498,15 +498,14 @@ int cx25821_video_register(struct cx25821_dev *dev)
dev->channels[i].timeout_data.dev = dev;
dev->channels[i].timeout_data.channel =
&cx25821_sram_channels[i];
- dev->channels[i].vidq.timeout.function =
- cx25821_vid_timeout;
+ dev->channels[i].vidq.timeout.function = cx25821_vid_timeout;
dev->channels[i].vidq.timeout.data =
(unsigned long)&dev->channels[i].timeout_data;
init_timer(&dev->channels[i].vidq.timeout);
/* register v4l devices */
- dev->channels[i].video_dev = cx25821_vdev_init(dev,
- dev->pci, &cx25821_video_device, "video");
+ dev->channels[i].video_dev = cx25821_vdev_init(dev, dev->pci,
+ &cx25821_video_device, "video");
err = video_register_device(dev->channels[i].video_dev,
VFL_TYPE_GRABBER, video_nr[dev->nr]);
@@ -619,10 +618,9 @@ int cx25821_buffer_prepare(struct videobuf_queue *q, struct videobuf_buffer *vb,
dev->tvnorm & V4L2_STD_PAL_DK)
bpl_local = 352 << 1;
else
- bpl_local =
- dev->channels[channel_opened].
- cif_width <<
- 1;
+ bpl_local = dev->channels[
+ channel_opened].
+ cif_width << 1;
}
}
}
@@ -846,11 +844,10 @@ static int video_open(struct file *file)
v4l2_prio_open(&dev->channels[ch_id].prio, &fh->prio);
- videobuf_queue_sg_init(&fh->vidq, &cx25821_video_qops,
- &dev->pci->dev, &dev->slock,
- V4L2_BUF_TYPE_VIDEO_CAPTURE,
- V4L2_FIELD_INTERLACED,
- sizeof(struct cx25821_buffer), fh, NULL);
+ videobuf_queue_sg_init(&fh->vidq, &cx25821_video_qops, &dev->pci->dev,
+ &dev->slock, V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ V4L2_FIELD_INTERLACED, sizeof(struct cx25821_buffer),
+ fh, NULL);
dprintk(1, "post videobuf_queue_init()\n");
mutex_unlock(&cx25821_devlist_mutex);
@@ -1166,8 +1163,8 @@ int cx25821_vidioc_querycap(struct file *file, void *priv,
strlcpy(cap->card, cx25821_boards[dev->board].name, sizeof(cap->card));
sprintf(cap->bus_info, "PCIe:%s", pci_name(dev->pci));
cap->version = CX25821_VERSION_CODE;
- cap->capabilities =
- V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
+ cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE |
+ V4L2_CAP_STREAMING;
if (UNSET != dev->tuner_type)
cap->capabilities |= V4L2_CAP_TUNER;
return 0;
@@ -1897,8 +1894,8 @@ static long video_ioctl_set(struct file *file, unsigned int cmd,
}
if (selected_channel <= 7 && selected_channel >= 0) {
- dev->channels[selected_channel].
- use_cif_resolution = cif_enable;
+ dev->channels[selected_channel].use_cif_resolution =
+ cif_enable;
dev->channels[selected_channel].cif_width = width;
} else {
for (i = 0; i < VID_CHANNEL_NUM; i++) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 36/36] Staging: cx25821: cx25821.h: Line up defines
From: Leonid V. Fedorenchik @ 2011-10-22 5:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, Leonid V. Fedorenchik,
devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
Line up constant defines to the same column.
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
---
drivers/staging/cx25821/cx25821.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821.h b/drivers/staging/cx25821/cx25821.h
index db2615b..0b3e13b 100644
--- a/drivers/staging/cx25821/cx25821.h
+++ b/drivers/staging/cx25821/cx25821.h
@@ -67,7 +67,7 @@
#define MAX_CAMERAS 16
/* Max number of inputs by card */
-#define MAX_CX25821_INPUT 8
+#define MAX_CX25821_INPUT 8
#define INPUT(nr) (&cx25821_boards[dev->board].input[nr])
#define RESOURCE_VIDEO0 1
#define RESOURCE_VIDEO1 2
@@ -85,7 +85,7 @@
#define BUFFER_TIMEOUT (HZ) /* 0.5 seconds */
-#define UNKNOWN_BOARD 0
+#define UNKNOWN_BOARD 0
#define CX25821_BOARD 1
/* Currently supported by the driver */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 01/11] swiotlb: Expose swiotlb_nr_tlb function to modules
From: FUJITA Tomonori @ 2011-10-22 4:49 UTC (permalink / raw)
To: konrad.wilk
Cc: linux-kernel, dri-devel, thellstrom, thomas, airlied, xen-devel,
j.glisse, bskeggs, fujita.tomonori
In-Reply-To: <1319062772-2793-2-git-send-email-konrad.wilk@oracle.com>
On Wed, 19 Oct 2011 18:19:22 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> We also fix the spelling - it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> [v1: Ripped out swiotlb_enabled]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> drivers/xen/swiotlb-xen.c | 2 +-
> include/linux/swiotlb.h | 2 +-
> lib/swiotlb.c | 5 +++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Nai Xia @ 2011-10-22 5:52 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <20111021225008.GK608@redhat.com>
On Saturday 22 October 2011 06:50:08 Andrea Arcangeli wrote:
> On Fri, Oct 21, 2011 at 07:41:20PM +0200, Andrea Arcangeli wrote:
> > We have two options:
> >
> > 1) we remove the vma_merge call from copy_vma and we do the vma_merge
> > manually after mremap succeed (so then we're as safe as fork is and we
> > relay on the ordering). No locks but we'll just do 1 more allocation
> > for one addition temporary vma that will be removed after mremap
> > completed.
> >
> > 2) Hugh's original fix.
>
> 3) put the src vma at the tail if vma_merge succeeds and the src vma
> and dst vma aren't the same
>
> I tried to implement this but I'm still wondering about the safety of
> this with concurrent processes all calling mremap at the same time on
> the same anon_vma same_anon_vma list, the reasoning I think it may be
> safe is in the comment. I run a few mremap with my benchmark where the
> THP aware mremap in -mm gets a x10 boost and moves 5G and it didn't
BTW, I am curious about what benchmark did you run and " x10 boost"
meaning compared to Hugh's anon_vma_locking fix?
> crash but that's about it and not conclusive, if you review please
> comment...
My comment is at the bottom of this post.
>
> I've to pack luggage and prepare to fly to KS tomorrow so I may not be
> responsive in the next few days.
>
> ===
> From f2898ff06b5a9a14b9d957c7696137f42a2438e9 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli <aarcange@redhat.com>
> Date: Sat, 22 Oct 2011 00:11:49 +0200
> Subject: [PATCH] mremap: enforce rmap src/dst vma ordering in case of
> vma_merge succeeding in copy_vma
>
> migrate was doing a rmap_walk with speculative lock-less access on
> pagetables. That could lead it to not serialize properly against
> mremap PT locks. But a second problem remains in the order of vmas in
> the same_anon_vma list used by the rmap_walk.
>
> If vma_merge would succeed in copy_vma, the src vma could be placed
> after the dst vma in the same_anon_vma list. That could still lead
> migrate to miss some pte.
>
> This patch adds a anon_vma_order_tail() function to force the dst vma
> at the end of the list before mremap starts to solve the problem.
>
> If the mremap is very large and there are a lots of parents or childs
> sharing the anon_vma root lock, this should still scale better than
> taking the anon_vma root lock around every pte copy practically for
> the whole duration of mremap.
> ---
> include/linux/rmap.h | 1 +
> mm/mmap.c | 8 ++++++++
> mm/rmap.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 2148b12..45eb098 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -120,6 +120,7 @@ void anon_vma_init(void); /* create anon_vma_cachep */
> int anon_vma_prepare(struct vm_area_struct *);
> void unlink_anon_vmas(struct vm_area_struct *);
> int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
> +void anon_vma_order_tail(struct vm_area_struct *);
> int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
> void __anon_vma_link(struct vm_area_struct *);
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index a65efd4..a5858dc 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
> */
> if (vma_start >= new_vma->vm_start &&
> vma_start < new_vma->vm_end)
> + /*
> + * No need to call anon_vma_order_tail() in
> + * this case because the same PT lock will
> + * serialize the rmap_walk against both src
> + * and dst vmas.
> + */
> *vmap = new_vma;
> + else
> + anon_vma_order_tail(new_vma);
> } else {
> new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
> if (new_vma) {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 8005080..170cece 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -272,6 +272,49 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
> }
>
> /*
> + * Some rmap walk that needs to find all ptes/hugepmds without false
> + * negatives (like migrate and split_huge_page) running concurrent
> + * with operations that copy or move pagetables (like mremap() and
> + * fork()) to be safe depends the anon_vma "same_anon_vma" list to be
> + * in a certain order: the dst_vma must be placed after the src_vma in
> + * the list. This is always guaranteed by fork() but mremap() needs to
> + * call this function to enforce it in case the dst_vma isn't newly
> + * allocated and chained with the anon_vma_clone() function but just
> + * an extension of a pre-existing vma through vma_merge.
> + *
> + * NOTE: the same_anon_vma list can still changed by other processes
> + * while mremap runs because mremap doesn't hold the anon_vma mutex to
> + * prevent modifications to the list while it runs. All we need to
> + * enforce is that the relative order of this process vmas isn't
> + * changing (we don't care about other vmas order). Each vma
> + * corresponds to an anon_vma_chain structure so there's no risk that
> + * other processes calling anon_vma_order_tail() and changing the
> + * same_anon_vma list under mremap() will screw with the relative
> + * order of this process vmas in the list, because we won't alter the
> + * order of any vma that isn't belonging to this process. And there
> + * can't be another anon_vma_order_tail running concurrently with
> + * mremap() coming from this process because we hold the mmap_sem for
> + * the whole mremap(). fork() ordering dependency also shouldn't be
> + * affected because we only care that the parent vmas are placed in
> + * the list before the child vmas and anon_vma_order_tail won't reorder
> + * vmas from either the fork parent or child.
> + */
> +void anon_vma_order_tail(struct vm_area_struct *dst)
> +{
> + struct anon_vma_chain *pavc;
> + struct anon_vma *root = NULL;
> +
> + list_for_each_entry_reverse(pavc, &dst->anon_vma_chain, same_vma) {
> + struct anon_vma *anon_vma = pavc->anon_vma;
> + VM_BUG_ON(pavc->vma != dst);
> + root = lock_anon_vma_root(root, anon_vma);
> + list_del(&pavc->same_anon_vma);
> + list_add_tail(&pavc->same_anon_vma, &anon_vma->head);
> + }
> + unlock_anon_vma_root(root);
> +}
This patch and together with the reasoning looks good to me.
But I wondering this patch can make the anon_vma chain ordering game more
complex and harder to play in the future.
However, if it does bring much perfomance benefit, I vote for this patch
because it balances all three requirements here: bug free, performance &
no two VMAs stay not merged for no good reason.
Our situation again makes me have the strong feeling that we are really
in bad need of a computer aided way to travel all possible state space.
There are some guys around me who do automatic software testing research.
But I am afraid our problem is too much "real world" for them... sigh...
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Nai Xia @ 2011-10-22 5:52 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <20111021225008.GK608@redhat.com>
On Saturday 22 October 2011 06:50:08 Andrea Arcangeli wrote:
> On Fri, Oct 21, 2011 at 07:41:20PM +0200, Andrea Arcangeli wrote:
> > We have two options:
> >
> > 1) we remove the vma_merge call from copy_vma and we do the vma_merge
> > manually after mremap succeed (so then we're as safe as fork is and we
> > relay on the ordering). No locks but we'll just do 1 more allocation
> > for one addition temporary vma that will be removed after mremap
> > completed.
> >
> > 2) Hugh's original fix.
>
> 3) put the src vma at the tail if vma_merge succeeds and the src vma
> and dst vma aren't the same
>
> I tried to implement this but I'm still wondering about the safety of
> this with concurrent processes all calling mremap at the same time on
> the same anon_vma same_anon_vma list, the reasoning I think it may be
> safe is in the comment. I run a few mremap with my benchmark where the
> THP aware mremap in -mm gets a x10 boost and moves 5G and it didn't
BTW, I am curious about what benchmark did you run and " x10 boost"
meaning compared to Hugh's anon_vma_locking fix?
> crash but that's about it and not conclusive, if you review please
> comment...
My comment is at the bottom of this post.
>
> I've to pack luggage and prepare to fly to KS tomorrow so I may not be
> responsive in the next few days.
>
> ===
> From f2898ff06b5a9a14b9d957c7696137f42a2438e9 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli <aarcange@redhat.com>
> Date: Sat, 22 Oct 2011 00:11:49 +0200
> Subject: [PATCH] mremap: enforce rmap src/dst vma ordering in case of
> vma_merge succeeding in copy_vma
>
> migrate was doing a rmap_walk with speculative lock-less access on
> pagetables. That could lead it to not serialize properly against
> mremap PT locks. But a second problem remains in the order of vmas in
> the same_anon_vma list used by the rmap_walk.
>
> If vma_merge would succeed in copy_vma, the src vma could be placed
> after the dst vma in the same_anon_vma list. That could still lead
> migrate to miss some pte.
>
> This patch adds a anon_vma_order_tail() function to force the dst vma
> at the end of the list before mremap starts to solve the problem.
>
> If the mremap is very large and there are a lots of parents or childs
> sharing the anon_vma root lock, this should still scale better than
> taking the anon_vma root lock around every pte copy practically for
> the whole duration of mremap.
> ---
> include/linux/rmap.h | 1 +
> mm/mmap.c | 8 ++++++++
> mm/rmap.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index 2148b12..45eb098 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -120,6 +120,7 @@ void anon_vma_init(void); /* create anon_vma_cachep */
> int anon_vma_prepare(struct vm_area_struct *);
> void unlink_anon_vmas(struct vm_area_struct *);
> int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
> +void anon_vma_order_tail(struct vm_area_struct *);
> int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
> void __anon_vma_link(struct vm_area_struct *);
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index a65efd4..a5858dc 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
> */
> if (vma_start >= new_vma->vm_start &&
> vma_start < new_vma->vm_end)
> + /*
> + * No need to call anon_vma_order_tail() in
> + * this case because the same PT lock will
> + * serialize the rmap_walk against both src
> + * and dst vmas.
> + */
> *vmap = new_vma;
> + else
> + anon_vma_order_tail(new_vma);
> } else {
> new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
> if (new_vma) {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 8005080..170cece 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -272,6 +272,49 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
> }
>
> /*
> + * Some rmap walk that needs to find all ptes/hugepmds without false
> + * negatives (like migrate and split_huge_page) running concurrent
> + * with operations that copy or move pagetables (like mremap() and
> + * fork()) to be safe depends the anon_vma "same_anon_vma" list to be
> + * in a certain order: the dst_vma must be placed after the src_vma in
> + * the list. This is always guaranteed by fork() but mremap() needs to
> + * call this function to enforce it in case the dst_vma isn't newly
> + * allocated and chained with the anon_vma_clone() function but just
> + * an extension of a pre-existing vma through vma_merge.
> + *
> + * NOTE: the same_anon_vma list can still changed by other processes
> + * while mremap runs because mremap doesn't hold the anon_vma mutex to
> + * prevent modifications to the list while it runs. All we need to
> + * enforce is that the relative order of this process vmas isn't
> + * changing (we don't care about other vmas order). Each vma
> + * corresponds to an anon_vma_chain structure so there's no risk that
> + * other processes calling anon_vma_order_tail() and changing the
> + * same_anon_vma list under mremap() will screw with the relative
> + * order of this process vmas in the list, because we won't alter the
> + * order of any vma that isn't belonging to this process. And there
> + * can't be another anon_vma_order_tail running concurrently with
> + * mremap() coming from this process because we hold the mmap_sem for
> + * the whole mremap(). fork() ordering dependency also shouldn't be
> + * affected because we only care that the parent vmas are placed in
> + * the list before the child vmas and anon_vma_order_tail won't reorder
> + * vmas from either the fork parent or child.
> + */
> +void anon_vma_order_tail(struct vm_area_struct *dst)
> +{
> + struct anon_vma_chain *pavc;
> + struct anon_vma *root = NULL;
> +
> + list_for_each_entry_reverse(pavc, &dst->anon_vma_chain, same_vma) {
> + struct anon_vma *anon_vma = pavc->anon_vma;
> + VM_BUG_ON(pavc->vma != dst);
> + root = lock_anon_vma_root(root, anon_vma);
> + list_del(&pavc->same_anon_vma);
> + list_add_tail(&pavc->same_anon_vma, &anon_vma->head);
> + }
> + unlock_anon_vma_root(root);
> +}
This patch and together with the reasoning looks good to me.
But I wondering this patch can make the anon_vma chain ordering game more
complex and harder to play in the future.
However, if it does bring much perfomance benefit, I vote for this patch
because it balances all three requirements here: bug free, performance &
no two VMAs stay not merged for no good reason.
Our situation again makes me have the strong feeling that we are really
in bad need of a computer aided way to travel all possible state space.
There are some guys around me who do automatic software testing research.
But I am afraid our problem is too much "real world" for them... sigh...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Any wireless cards with this debug capability?
From: Adrian Chadd @ 2011-10-22 6:03 UTC (permalink / raw)
To: George Nychis; +Cc: linux-wireless@vger.kernel.org, Eric Rozner
In-Reply-To: <2764633066252075767@unknownmsgid>
On 22 October 2011 05:09, George Nychis <gnychis@gmail.com> wrote:
> We are finding that under certain scenarios, various WiFi cards
> (Atheros, Intel, ...) fail to decode incoming packets for certain
> periods of time on the order of 5->20ms. We are trying to enable a
> low-latency wireless link in which losses during this window break our
> requirement. A retransmission would essentially be too late.
>
> During this period, we are trying to determine the reason for loss.
> Whether it is fading, improper tuning of AGC, failure to account for
> frequency offset, etc. Ideally, what we would like to know is whether
> the card *tried* to acquire the carrier and if so, where it failed. I
> have noticed several Atheros kernel debug counters which show things
> such as a PHY error, but it's not clear at what stage it failed.
If you're not doing stupidly-high RX throughput, you could enable PHY
errors on the Atheros NICs instead of Just relying on the counters.
That way you can get reason values for the failed RX frames.
It may not be the -exact- reason (having the AGC get upset at you for
20ms? That seems a bit unlikely, considering how quick it needs to
adjust at the beginning of every RX'ed signal that may be a data
frame..) but it could be something like ANI interfering with RX.
There's been at least one reproducable report of that occuring w/
ath9k + AR5416 however I've not seen it happen on my FreeBSD/Linux
setups. For atheros, it could also be the periodic calibration code
kicking in.
I'd start by enabling PHY errors and watching the values of counters
whenever the error condition occurs. Under FreeBSD the 'athstats' tool
(and all the data exported by the HAL and driver) has allowed me to
leverage some basic correlational techniques to find/fix issues. You
may be able to do the same with a bit of hackery and the debugfs
export of these counters with ath5k/ath9k.
I think you can also enable receiving frames which fail the CRC check.
I forget if that is enabled by default.
Adrian
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: Ari Savolainen @ 2011-10-22 6:12 UTC (permalink / raw)
To: RongQing Li
Cc: Eric Dumazet, David Miller, richardcochran, netdev, linux-kernel
In-Reply-To: <CAJFZqHzWUsP7szrjVwmW5+HWRND3R4qxWcnK=bqbsgL6F7XGeA@mail.gmail.com>
2011/10/21 RongQing Li <roy.qing.li@gmail.com>:
> Hi Ari:
>
> Are you sure the patch is applied correctly and the log is same?
> If the log is not same, could you paste it again.
>
> Thanks
Yes, I'm sure. The panic and the rcu splat are unrelated. The panic
occurs when skb_tx_timestamp is being called after skb having been
freed by tigon3_dma_hwbug_workaround.
Ari
^ permalink raw reply
* Re: Simulating faulty disk
From: Yathindra @ 2011-10-22 6:16 UTC (permalink / raw)
To: Bryn M. Reeves, device-mapper development
In-Reply-To: <4EA18DF3.3000800@redhat.com>
All I want to do is simulate a delay or flakey device. Mount it. And see
how regular read/write commands
such as cat, echo, vim etc behave.
* I created a delay device d0 and mounted it on /mnt
* Copied few files into /mnt
* Invoked dd command on /dev/mapper/d0 and it was slow
* Invoked cat command on some file in /mnt but it was not slow
What is wrong here?
Steps I followed are shown below:
==========================================================
root@nodea:/users/ydev# dmsetup remove_all
#Created a delay device d0
root@nodea:/users/ydev# dmsetup create d0 --table="0 `blockdev --getsize
/dev/sdb` delay /dev/sdb 0 500"
#Put a filesystem on top of d0
root@nodea:/users/ydev# mkfs -t ext3 /dev/mapper/d0
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
....
....
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
....
#Mounted the device-mapper device on /mnt.
root@nodea:/users/ydev# mount -t ext3 /dev/mapper/d0 /mnt
#Copied some arbitrary files into /mnt
root@nodea:/users/ydev# cp -r stap_tests /mnt
#Invoked a dd command to check if it is slowing down and it did as seen
below.
root@nodea:/# dd if=/dev/mapper/d0 of=/dev/null bs=400k count=1
1+0 records in
1+0 records out
409600 bytes (410 kB) copied, 1.01523 s, 403 kB/s
#But it did not slow down cat command as seen below.
root@nodea:/mnt/stap_tests# sysctl vm.drop_caches=3
vm.drop_caches = 3
root@nodea:/mnt/stap_tests# time cat 12M > /dev/null
real 0m0.034s
user 0m0.000s
sys 0m0.004s
==========================================================
Thanks,
Yathi
On 10/21/2011 9:21 AM, Bryn M. Reeves wrote:
> On 10/21/2011 04:13 PM, Yathindra wrote:
>> >mount -t ext3 /dev/sdb /mnt
>> Copied some data into /mnt
>> >dmsetup create d0 --table="0 `blockdev --getsize /dev/sdb` delay
>> /dev/sdb 0 500"
>> device-mapper: reload ioctl failed: Invalid argument
>> Command failed
>
> You can't create a mapped device on something while it is mounted as
> device-mapper needs to open it exclusively.
>
>> But as seen from above, dmsetup is failing to create a flakey/delay
>> device when /dev/sdb
>> has a filesystem on top of it. Is there any workaround ?
>
> Set up the file system the way you want it on sdb first. Then unmount
> it and create the device-mapper devices and mount that.
>
> Regards,
> Bryn.
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Nai Xia @ 2011-10-22 6:21 UTC (permalink / raw)
To: Paweł Sikora
Cc: Hugh Dickins, arekm, Linus Torvalds, linux-mm, Mel Gorman,
jpiszcz, linux-kernel, Andrew Morton, Andrea Arcangeli
In-Reply-To: <201110212336.47267.pluto@agmk.net>
On Saturday 22 October 2011 05:36:46 Paweł Sikora wrote:
> On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > >
> > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > >
> > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > afaics all userspace applications usualy don't use more than half of physical memory
> > > and so called "cache" on htop bar doesn't reach the 100%.
> >
> > OK，did you logged any OOM killing if there was some memory usage burst?
> > But, well my above OOM reasoning is a direct short cut to imagined
> > root cause of "adjacent VMAs which
> > should have been merged but in fact not merged" case.
> > Maybe there are other cases that can lead to this or maybe it's
> > totally another bug....
>
> i don't see any OOM killing with my conservative settings
> (vm.overcommit_memory=2, vm.overcommit_ratio=100).
OK, that does not matter now. Andrea showed us a simpler way to goto
this bug.
>
> > But still I think if my reasoning is good, similar bad things will
> > happen again some time in the future,
> > even if it was not your case here...
> >
> > >
> > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > steps and stress this machine again...
> >
> > OK, it's smart to narrow down the range first....
>
> disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> average load ~16. i wonder if it survive weekend...
>
Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Nai Xia @ 2011-10-22 6:21 UTC (permalink / raw)
To: Paweł Sikora
Cc: Hugh Dickins, arekm, Linus Torvalds, linux-mm, Mel Gorman,
jpiszcz, linux-kernel, Andrew Morton, Andrea Arcangeli
In-Reply-To: <201110212336.47267.pluto@agmk.net>
On Saturday 22 October 2011 05:36:46 Paweł Sikora wrote:
> On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > >
> > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > >
> > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > afaics all userspace applications usualy don't use more than half of physical memory
> > > and so called "cache" on htop bar doesn't reach the 100%.
> >
> > OK，did you logged any OOM killing if there was some memory usage burst?
> > But, well my above OOM reasoning is a direct short cut to imagined
> > root cause of "adjacent VMAs which
> > should have been merged but in fact not merged" case.
> > Maybe there are other cases that can lead to this or maybe it's
> > totally another bug....
>
> i don't see any OOM killing with my conservative settings
> (vm.overcommit_memory=2, vm.overcommit_ratio=100).
OK, that does not matter now. Andrea showed us a simpler way to goto
this bug.
>
> > But still I think if my reasoning is good, similar bad things will
> > happen again some time in the future,
> > even if it was not your case here...
> >
> > >
> > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > steps and stress this machine again...
> >
> > OK, it's smart to narrow down the range first....
>
> disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> average load ~16. i wonder if it survive weekend...
>
Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Congratulations
From: BBC NATIONAL PROMO @ 2011-10-22 5:03 UTC (permalink / raw)
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND,
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,£1.000,000 (one
million pounds) in the British Broadcasting corporation (BBC) Online Promo
Held on this month of 21st October 2011,and you are to acknowledge the
receipt of this mail with the details below to.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Congratulations
From: BBC NATIONAL PROMO @ 2011-10-22 5:03 UTC (permalink / raw)
BBC E-MAIL PROMOTION WINNERS NOTICE,
WINNING NOTIFICATION !!!
BBC NATIONAL LOTTERY PROMO
UK HEAD OFFICE.
SUITES 23-30,LION TOWERS
CENTRAL LONDON
ENGLAND,
http://www.bbc.co.uk/lottery/
Your Email Address was selected thereby Winning for you,£1.000,000 (one
million pounds) in the British Broadcasting corporation (BBC) Online Promo
Held on this month of 21st October 2011,and you are to acknowledge the
receipt of this mail with the details below to.
1.Full name:
2.Tel:
3.Country :
Sincerely,
Mr. Scott Carson
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [Xenomai-help] forge: license files
From: Philippe Gerum @ 2011-10-22 6:34 UTC (permalink / raw)
To: Thomas De Schampheleire; +Cc: Xenomai-help
In-Reply-To: <CAAXf6LVJ_V4QKQ6=fubVc1o45Hq=XNHLEVd8Qx-hTF7gsheDoQ@mail.gmail.com>
On Fri, 2011-10-21 at 12:37 +0200, Thomas De Schampheleire wrote:
> Hi,
>
> With respect to the source code license of xenomai-forge: there is no
> COPYING file in lib/psos, while there is one in most other
> subdirectories.
> I didn't check all other directories, but I guess you know better than
> me where there should be such a file.
Thanks for the heads up. I'll add it in due time, since this is a
definite hint about the license being used. However, the LGPL header is
present in the psos files anyway, so this information is already
available and pretty clear.
>
> Best regards,
> Thomas
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply
* Re: [patch 5/5] elf: Add support for loading ET_CKPT files
From: Pavel Emelyanov @ 2011-10-22 6:34 UTC (permalink / raw)
To: Tejun Heo, Cyrill Gorcunov
Cc: linux-kernel@vger.kernel.org, Andrey Vagin, James Bottomley,
Glauber Costa, H. Peter Anvin, Ingo Molnar, Dave Hansen,
Eric W. Biederman, Daniel Lezcano, Alexey Dobriyan,
Linus Torvalds, Oleg Nesterov
In-Reply-To: <20111021184817.GC28670@google.com>
On 10/21/2011 10:48 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Oct 21, 2011 at 10:42:39PM +0400, Cyrill Gorcunov wrote:
>> On Fri, Oct 21, 2011 at 10:36:28PM +0400, Cyrill Gorcunov wrote:
>>>> I think this comes back to why one-stop-solution-in-kernel is a bad
>>>> idea for CR. My impression is that when people say "that would
>>>> require too many small API updatesa", it usually means that they
>>>> haven't really thought about each necessary piece enough and just
>>
>> Don't claim such things, Tejun. Yes, I'm missing a number of things
>> (the same applies to you as well), but this patch was not 'just a
>> fast way to achieve what we need'. It's rather an attempt to gather
>> all things I've missed and provide more robust/solid version at the
>> next iteration (regargless which form this patch appeared, complete
>> user-space solution, some kernel api extension of whatever).
>
> Hmmm... my point was that single lumpy implementation allows for such
> mistakes to go unnoticed && makes it difficult to recover and thus is
> a bad approach to the problem. For example, unlikely but, let's say
> we missed this vdso thing and it went into upstream, now what would we
> do? We'll need to somehow allow userland supply vdso symtab to kernel
> and let the kernel do the bridging and then probably bump the version
> number for elf format and so on. IMHO, that just isn't a good way to
> approach the problem, so let's please do it piece by piece.
What mistakes are we talking about?
With the seized restore we prepare the VDSO thing in the userspace and
then push this in to the kernel (let alone the question how we make the
kernel know this page IS VDSO), with the exec-ed restore we also prepare
this VDSO in the userspace and then push this into the kernel as well, but
via the binary handler. This handler is extremely simple thing and not
supposed to do complex logic - just call do_mmap_pgoff() and write pages
in there in cycle, which is generic enough even for VDSO, no?
What am I missing here, where is the difference? Don't get me wrong, I'm
not mocking, just assume that we can all miss smth from each other.
> Thanks.
>
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: Eric Dumazet @ 2011-10-22 6:37 UTC (permalink / raw)
To: Ari Savolainen
Cc: RongQing Li, David Miller, richardcochran, netdev, linux-kernel
In-Reply-To: <CAEbykaVJneQ0ozUvYh2PRn-p_BowL4z4_4Y8EFCdO9mOsNX7OQ@mail.gmail.com>
Le samedi 22 octobre 2011 à 09:12 +0300, Ari Savolainen a écrit :
> 2011/10/21 RongQing Li <roy.qing.li@gmail.com>:
> > Hi Ari:
> >
> > Are you sure the patch is applied correctly and the log is same?
> > If the log is not same, could you paste it again.
> >
> > Thanks
>
> Yes, I'm sure. The panic and the rcu splat are unrelated. The panic
> occurs when skb_tx_timestamp is being called after skb having been
> freed by tigon3_dma_hwbug_workaround.
OK that makes sense, thanks !
Do you plan to submit a patch, now you found the bug ?
^ permalink raw reply
* [PATCH v4 1/3] [media] at91: add code to enable/disable ISI_MCK clock
From: Wu, Josh @ 2011-10-22 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1110171702370.18438@axis700.grange>
Hi, Guennadi
On Monday, October 17, 2011 11:04 PM, Guennadi Liakhovetski wrote:
> From: Josh Wu <josh.wu@atmel.com>
>
> This patch
> - add ISI_MCK clock enable/disable code.
> - change field name in isi_platform_data structure
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> [g.liakhovetski at gmx.de: fix label names]
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> Josh, I missed a slight hick-up in the previous version of this your
> patch, so, I fixed it myself. Please confirm, that this version is ok
with
> you.
> Thanks
> Guennadi
I confirm that the patch is ok for me. Thank you.
Best Regards,
Josh Wu
^ permalink raw reply
* RE: [PATCH v4 1/3] [media] at91: add code to enable/disable ISI_MCK clock
From: Wu, Josh @ 2011-10-22 6:41 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-media, plagnioj, linux-kernel, linux-arm-kernel,
Ferre, Nicolas, s.nawrocki
In-Reply-To: <Pine.LNX.4.64.1110171702370.18438@axis700.grange>
Hi, Guennadi
On Monday, October 17, 2011 11:04 PM, Guennadi Liakhovetski wrote:
> From: Josh Wu <josh.wu@atmel.com>
>
> This patch
> - add ISI_MCK clock enable/disable code.
> - change field name in isi_platform_data structure
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> [g.liakhovetski@gmx.de: fix label names]
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> Josh, I missed a slight hick-up in the previous version of this your
> patch, so, I fixed it myself. Please confirm, that this version is ok
with
> you.
> Thanks
> Guennadi
I confirm that the patch is ok for me. Thank you.
Best Regards,
Josh Wu
^ permalink raw reply
* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: Maciej Żenczykowski @ 2011-10-22 6:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111022.000406.350185785547409199.davem@davemloft.net>
2011/10/21 David Miller <davem@davemloft.net>:
> From: Maciej Żenczykowski <zenczykowski@gmail.com>
> Date: Fri, 21 Oct 2011 15:22:05 -0700
>
>> From: Maciej Żenczykowski <maze@google.com>
>>
>> This change adds a sysctl (/proc/sys/net/core/allow_so_priority)
>> with a default of true (1), as such it does not change the default
>> behaviour of the Linux kernel.
>>
>> This sysctl can be set to false (0), this will result in non
>> CAP_NET_ADMIN processes being unable to set SO_PRIORITY socket
>> option.
>>
>> This is desireable if we want to rely on socket/skb priorities
>> being inferred from TOS/TCLASS bits.
>>
>> Signed-off-by: Maciej Żenczykowski <maze@google.com>
>
> The socket layer is not the place to enforce this.
>
> The ingress into your MPLS/RSVP cloud that actually provides the
> quality of service is where you control and mangle the TOS as needed.
>
> Sorry, I'm not applying anything like this. Any machine on your
> network can spit out any TOS it wants, and if you have control over
> the apps change it's behavior there. If you don't have control over
> the apps then filter and mangle.
Hmm, so I already have container (cgroup) limits on what TOS settings,
a process is allowed to set (query: would you be interested in accepting a patch
for that at some point in the future?).
Normally setting IP_TOS also automatically sets sock->sk_priority
(based on a mapping), which
gets inherited into skb->priority, which can then be used for stuff
like hardware
priority queue dispatch (basically xps + skb->priority queue selection).
Either via an XPS like mechanism, or a QDISC like mechanism (preferred), or
an in-driver mechanism (currently have a hack which does this).
However, processes can also manually override the sk_priority by calling
SO_PRIORITY directly, at which point their IP_TOS and SO_PRIORITY no
longer match.
This patch allows you to disable this ability. It's not affecting the
on-the-wire bits
in any way, it's really only affecting packet classification at the
qdisc and in the driver.
As you can see this patch isn't about TOS, it's about the kernel
internal skb priority setting.
On a related note, while setting IP_TOS sets sk_priority, setting
IPV6_TCLASS does not
set sk_priority. I'd like to see this behaviour be consistent. As
such was planning on
sending you a patch to add sk_priority = rt_tos2priority(val) to the
IPV6_TCLASS setsockopt
code path. Is that ok?
- Maciej
^ permalink raw reply
* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: David Miller @ 2011-10-22 6:58 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev
In-Reply-To: <CAHo-OoxtAmzPjr4R7jQOk9GGQo7i-qVmoaY8vTYDQDj1HXsPNA@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Fri, 21 Oct 2011 23:49:00 -0700
> However, processes can also manually override the sk_priority by calling
> SO_PRIORITY directly, at which point their IP_TOS and SO_PRIORITY no
> longer match.
>
> This patch allows you to disable this ability.
I also don't see why we'd want to allow disabling this either.
I really hate these patches that offer ways to disable things
that normally work, and thus break apps when the non-default
is selected.
I kind of have a feeling the kind of situation you're trying to
account for, you have some cloud where people run random stuff
that you don't control.
But you didn't specify this, and we just have to guess. Why don't you
describe the specific situation where you want to modify this setting?
Please do this instead of just talking about what the side effects are
inside of the kernel. That's much less interesting when it comes to
patches like this.
^ permalink raw reply
* Re: [PATCH 0/7] writeback: avoid touching dirtied_when on blocked inodes
From: Wu Fengguang @ 2011-10-22 6:59 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fsdevel@vger.kernel.org, Dave Chinner, Christoph Hellwig,
Andrew Morton, LKML, Tang, Feng
In-Reply-To: <20111022053851.GA23033@localhost>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
> In general it looks better we first root case the "decreasing wrote
> pages by writeback_single_inode() over time" problem before looking
> into further steps..
The problem shows up in many of the regression cases. For example,
the thresh=1G/ext4-100dd case with patches 1-4 applied will not only
see nr_writeback occasionally dropped low (bdi_dirty_state-8:0.png),
but also see repeated pattern of nr_wrote by writeback_single_inode()
slowly decreasing to 0 during some period of dozens of seconds
(writeback_single_inode.png).
Thanks,
Fengguang
[-- Attachment #2: bdi_dirty_state-8:0.png --]
[-- Type: image/png, Size: 42728 bytes --]
[-- Attachment #3: balance_dirty_pages-pages.png --]
[-- Type: image/png, Size: 85151 bytes --]
[-- Attachment #4: writeback_single_inode.png --]
[-- Type: image/png, Size: 52548 bytes --]
[-- Attachment #5: iostat-misc.png --]
[-- Type: image/png, Size: 102612 bytes --]
^ permalink raw reply
* bad tree block start
From: Helmut Hullen @ 2011-10-22 7:05 UTC (permalink / raw)
To: linux-btrfs
Hallo,
my system now shows in "dmesg"
btrfs bad tree block start 0 5064615628800
btrfs bad tree block start 0 5064615632896
btrfs bad tree block start 0 5064615665664
btrfs bad tree block start 0 5064615624704
btrfs bad tree block start 0 5064615628800
btrfs bad tree block start 0 5064615632896
btrfs bad tree block start 0 5064615665664
btrfs bad tree block start 0 5064615624704
Can I repair it? If yes: how?
Kernel 2.6.39.4
btrfs from the "Hugo Mills" tree.
Cluster of 3 Disks, data raid0, metadata raid 1.
Disks: 3* 2TByte, filled with more than 4 TByte.
Viele Gruesse!
Helmut
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.