* I2C_RDRW_IOCTL_MAX_MSGS
From: Srinivasan, Nageswari @ 2012-01-17 10:56 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi,
Is there any specific reason to limit no of i2c messages
to 42 in i2c-dev.c file
/* Put an arbitrary limit on the number of messages that can
* be sent at once */
if (rdwr_arg.nmsgs > I2C_RDRW_IOCTL_MAX_MSGS)
return -EINVAL;
Regards,
Nageswari
^ permalink raw reply
* Re: [patch 2/3] intel_idle: disable auto_demotion for hotplugged CPUs
From: Thomas Renninger @ 2012-01-17 10:56 UTC (permalink / raw)
To: akpm; +Cc: lenb, len.brown, linux-acpi, shaohua.li
In-Reply-To: <20120110234820.B14B8100270@wpzn3.hot.corp.google.com>
On Wednesday, January 11, 2012 12:48:20 AM akpm@linux-foundation.org wrote:
> From: Shaohua Li <shaohua.li@intel.com>
> Subject: intel_idle: disable auto_demotion for hotplugged CPUs
This one should not be necessary anymore with my intel_idle
patch series I have to rebase and resend (will do that after lunch).
It provides a per cpu intel_idle init function which is called
from processor.ko in physical cpu hotplug case.
>From what I can see this patch does not change anything/much, because:
- CPUs onlined at bootup are initialized correctly already
- Soft offlining/onlining shouldn't matter in auto_demotion_disable
case as it's a HW MSR write and the CPU should still be in the
same state after off- and onlined again.
- Physically hotplugged/added CPUs are not registered with cpuidle
at all (this is what my patch series fixes), because intel_idle
does not offer any per cpu init() entry function.
With this patch they might be set into auto_demotion_disable now,
but no idle driver gets active for them.
I'll pick up patch 1/3 and 3/3, base my patches on top and resend
everything, that should be easiest for everybody?
Thomas
^ permalink raw reply
* Re: Boot error using 3.2.1: swapper (pid 1): Illegal instruction (code 8)
From: Rolf Eike Beer @ 2012-01-17 10:55 UTC (permalink / raw)
To: linux-parisc
In-Reply-To: <1326797664.3020.30.camel@dabdike>
> On Tue, 2012-01-17 at 11:41 +0100, Rolf Eike Beer wrote:
>> Machine is an Apollo 705, previous kernel version was 2.6.28. Any hints
>> appreciated. Config attached.
>
> Best guess is that your init binary is incompatible with the hardware
> architecture. It has to be compiled for PA7000 to work on an Apollo
> system.
Using the same init with kernel 2.6.28 works fine.
Eike
^ permalink raw reply
* [libibverbs bug] Passing negative size to ibv_rc_pingpong causes seg fault
From: Vasant Hegde @ 2012-01-17 10:54 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi all,
Issue:
ibv_rc_pingpong with negative size causes segfault
Steps :
run below command :
ibv_rc_pingpong -s -2048
Segmentation fault
Package source :
git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git
http://www.openfabrics.org/downloads/libibverbs/libibverbs-1.1.4-1.24.gb89d4d7.tar.gz
Solution :
Currently we are not validating the input size passed by user.
Adding input size validation fixes this issue.
Thanks
Vasant
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
From: Mark Brown @ 2012-01-17 10:54 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: arnd@arndb.de, greg@kroah.com, eric.piel@tremplin-utc.net,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Nori, Sekhar
In-Reply-To: <331ABD5ECB02734CA317220B2BBEABC13177CDA4@DBDE01.ent.ti.com>
On Tue, Jan 17, 2012 at 07:32:47AM +0000, AnilKumar, Chimata wrote:
> Recalling the patch, provide the comments if there are any if not please include
> this patch to v3.3 kernel.
There's no way this is going to make it into the 3.3 kernel at this
point, we're almost at the end of the merge window.
^ permalink raw reply
* Re: Boot error using 3.2.1: swapper (pid 1): Illegal instruction (code 8)
From: James Bottomley @ 2012-01-17 10:54 UTC (permalink / raw)
To: Rolf Eike Beer; +Cc: linux-parisc
In-Reply-To: <5333929.7Zifozzp4e@devpool02>
On Tue, 2012-01-17 at 11:41 +0100, Rolf Eike Beer wrote:
> Machine is an Apollo 705, previous kernel version was 2.6.28. Any hints
> appreciated. Config attached.
Best guess is that your init binary is incompatible with the hardware
architecture. It has to be compiled for PA7000 to work on an Apollo
system.
James
^ permalink raw reply
* Re: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
From: Guennadi Liakhovetski @ 2012-01-17 10:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Rupert Eibauer,
Hans Verkuil
In-Reply-To: <4F155252.2060705@redhat.com>
On Tue, 17 Jan 2012, Mauro Carvalho Chehab wrote:
> Em 17-01-2012 08:16, Guennadi Liakhovetski escreveu:
> > Hi Hans
> >
> > On Tue, 17 Jan 2012, Hans Verkuil wrote:
> >
> >> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote:
> >>> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote:
> >>>> This is an automatic generated email to let you know that the following
> >>>> patch were queued at the http://git.linuxtv.org/media_tree.git tree:
> >>>>
> >>>> Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
> >>>> Author: Hans Verkuil <hans.verkuil@cisco.com>
> >>>> Date: Wed Jan 11 07:37:54 2012 -0300
> >>>
> >>> [snip]
> >>>
> >>>> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> >>>> b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index
> >>>> fd45f1c..4533068 100644
> >>>> --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> >>>> +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> >>>> @@ -61,8 +61,9 @@ desired output in an integer and call the
> >>>>
> >>>> <constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this
> >>>> integer. Side effects are possible. For example outputs may support
> >>>> different video standards, so the driver may implicitly switch the
> >>>> current
> >>>>
> >>>> -standard. It is good practice to select an output before querying or
> >>>> -negotiating any other parameters.</para>
> >>>> +standard.
> >>>> +standard. Because of these possible side effects applications
> >>>> +must select an output before querying or negotiating any other
> >>>> parameters.</para>
> >>>
> >>> something seems to be wrong here.
> >>
> >> Hi Guennadi!
> >>
> >> What's wrong here? I've no idea what you mean.
> >
> >>>> +standard.
> >>>> +standard. Because of these possible side effects applications
> >
> > doesn't seem to make much sense?
>
> Are you referring to grammar?
Sorry, am I being blind? The above seems to produce
<quote>
different video standards, so the driver may implicitly switch the
current standard. standard. Because of these possible side effects
applications
</quote>
i.e., double "standard." - one too many.
Thanks
Guennadi
> I think that a comma is missing there [1]:
>
> Because of these possible side effects, applications
> must select an output before querying or negotiating any other
> parameters.
>
> IMO, reverting the order of the explanation clause is semantically better,
> as it bolds the need to select an output, and put the phrase at the
> cause-effect order:
>
> Applications must select an output before querying or negotiating
> any other parameters, because of these possible side effects.
>
> But this is really a matter of choice. In any case, except for the
> comma, that makes sense for me.
>
> [1] Rule 4 of http://grammar.ccc.commnet.edu/grammar/commas.htm
>
>
> Regards,
> Mauro
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] sh: fix the sh_mmcif_plat_data in board-sh7757lcr
From: Paul Mundt @ 2012-01-17 10:53 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F153622.3090701@renesas.com>
On Tue, Jan 17, 2012 at 05:49:38PM +0900, Shimoda, Yoshihiro wrote:
> The board has an eMMC chip, so we cannot remove the chip.
> In this case, we have to set the MMC_CAP_NONREMOVABLE to the caps
> parameter.
>
> Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error
From: Boaz Harrosh @ 2012-01-17 10:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Chinner, Jan Kara, linux-fsdevel, linux-ext4, Andrew Morton,
Christoph Hellwig, Al Viro, LKML, Edward Shishkin
In-Reply-To: <CA+55aFxZ8dF8WagoyQPYTm92R1ZKd0G_tztqmAc+jrv0LkWGAA@mail.gmail.com>
On 01/17/2012 02:59 AM, Linus Torvalds wrote:
> On Mon, Jan 16, 2012 at 4:36 PM, Dave Chinner <david@fromorbit.com> wrote:
>>
>> Jan is right, Linus. His definition of what up-to-date means for
>> dirty buffers is correct, especially in the case of write errors.
>
> It's not a dirty buffer any more.
>
> Go look. We've long since cleared the dirty bit.
>
> So stop spouting garbage.
>
> My argument is simple: the contents ARE NOT CORRECT ENOUGH to be
> called "up-to-date and clean".
>
> And I outlined the two choices:
>
> - mark it dirty and continue trying to write it out forever
>
> - invalidate it.
>
> Anything else is crazy talk. And marking it dirty forever isn't really
> an option. So..
>
> Linus
I think this conversation is an hint to the fact that the page_cache-page
state machine is clear as mud. And I thought it was only me. For years
I want to catch some VFS guru to sit down and finally explain to me all
the stages and how they are expressed in page-flag bits.
Back to the conversation. The way I understood it (Which is probably wrong)
1. The application dirties a page it is in a *dirty* state.
2. Write-out begins, page goes into that in-write-out state (Am I correct)
Now the page comes back from write-out with an error. As Linus stated we can
not put it back to *dirty* state because it will probably never clear.
(We did bunch of retrys on the block level). And we can't keep it in-write-out
surly. But I think we should surly *not* put it in *not-clean* state. Because
that one implies reading and the worse we can do is read that page as it is
now.
Therefor I agree with Jan. That the best is to use that extra error bit
to indicate an *error-state*, which is up to the FS to handle.
If it was a read error - error-is-set clean-is-cleared
If it was a write err - error-is-set clean-is-set.
All the rest of the Kernel should consider these as a they are error-sate
and I really like Jan's patch of inspecting for error-bit and not the
not-clean in a write-out which is darn confusing. (Regardless of the meaning
of the clean-bit)
Now the filesystem needs to do something about these pages like put them in a Jurnal,
shove them in a recovery workQ or whatever. All the VFS/MM can do is like Linus
said wait until they are plain removed which is effectively like invalidating them.
(In the case the FS did nothing to fix it)
I wish there was some heavy logging when the VFS/MM trashes error-set but clean-set
pages (Write-errors), even a write-out of these buffers to some global journal, of
which tools can extract and amend later. (Like the USB snatched too soon example)
So I see Linus point of "we can't go back to any of the old states" but let's not
overload the clean-bit and use the proper error-bit like Jan suggested.
My $0.017
Boaz
^ permalink raw reply
* Re: Is this a racing bug in page_make_sharable()?
From: Tim Deegan @ 2012-01-17 10:53 UTC (permalink / raw)
To: Nai Xia; +Cc: xen-devel, Grzegorz Milos
In-Reply-To: <CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
At 22:43 +0800 on 16 Jan (1326753834), Nai Xia wrote:
> Hi Grzegorz,
>
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
>
> ====
> /* Check if the ref count is 2. The first from PGT_allocated, and
> * the second from get_page_and_type at the top of this function */
> if(page->count_info != (PGC_allocated | (2 + expected_refcnt)))
> {
> /* Return type count back to zero */
> put_page_and_type(page);
> spin_unlock(&d->page_alloc_lock);
> return -E2BIG;
> }
> ====
>
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?
Yes, there are a number of races around the p2m code; Anders
Lagar-Cavilla has been working on fixing the locking around p2m lookups
to take care of this.
Tim.
^ permalink raw reply
* Re: Xen 4.2 TODO List Update
From: Olaf Hering @ 2012-01-17 10:53 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, Keir Fraser, George Dunlap, Ian Jackson, Tim Deegan,
Roger Pau Monne, Stefano Stabellini, Andres Lagar-Cavilla,
Jan Beulich, Anthony Perard
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
For libxl, it would be nice to have also libyajl2 support. OpenSuSE 11.4
was the last version which shipped libyajl1, 12.1 and later seem to have
just libyajl2.
Olaf
^ permalink raw reply
* Re: [GIT PULL] Samsung devel for v3.3
From: Mark Brown @ 2012-01-17 10:53 UTC (permalink / raw)
To: Olof Johansson
Cc: Kukjin Kim, Arnd Bergmann, linux-arm-kernel, linux-samsung-soc,
ben-linux
In-Reply-To: <CAOesGMiU+-wfxsfha7GTO3s7dHysP65gcrbJsLWhBpZNT9O+UQ@mail.gmail.com>
On Mon, Jan 16, 2012 at 10:40:17PM -0800, Olof Johansson wrote:
> The above two don't seem to have been in the branch that was sent by
> Kukjin, it had:
> ARM: EXYNOS: Invert VCLK polarity for framebuffer on ORIGEN
> ARM: S3C64XX: Fix interrupt configuration for PCA935x on Cragganmore
> ARM: S3C64XX: Fix the memory mapped GPIOs on Cragganmore
> ARM: S3C64XX: Remove hsmmc1 from Cragganmore
> ARM: S3C64XX: Remove unconditional power domain disables
> ARM: SAMSUNG: Declare struct platform_device in plat/s3c64xx-spi.h
> ARM: SAMSUNG: dma-ops.h needs mach/dma.h
> ARM: SAMSUNG: Guard against multiple inclusion of plat/dma.h
> I've pulled the branch from him.
I applied all the fixes I was sitting on that were in -next only at the
time I looked; stuff like this is part of the reason why I tend to avoid
topic branches unless they're likely to get merged in multiple places,
too much bookkeeping.
^ permalink raw reply
* [GIT PULL] Samsung devel for v3.3
From: Mark Brown @ 2012-01-17 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiU+-wfxsfha7GTO3s7dHysP65gcrbJsLWhBpZNT9O+UQ@mail.gmail.com>
On Mon, Jan 16, 2012 at 10:40:17PM -0800, Olof Johansson wrote:
> The above two don't seem to have been in the branch that was sent by
> Kukjin, it had:
> ARM: EXYNOS: Invert VCLK polarity for framebuffer on ORIGEN
> ARM: S3C64XX: Fix interrupt configuration for PCA935x on Cragganmore
> ARM: S3C64XX: Fix the memory mapped GPIOs on Cragganmore
> ARM: S3C64XX: Remove hsmmc1 from Cragganmore
> ARM: S3C64XX: Remove unconditional power domain disables
> ARM: SAMSUNG: Declare struct platform_device in plat/s3c64xx-spi.h
> ARM: SAMSUNG: dma-ops.h needs mach/dma.h
> ARM: SAMSUNG: Guard against multiple inclusion of plat/dma.h
> I've pulled the branch from him.
I applied all the fixes I was sitting on that were in -next only at the
time I looked; stuff like this is part of the reason why I tend to avoid
topic branches unless they're likely to get merged in multiple places,
too much bookkeeping.
^ permalink raw reply
* [PATCH] serial: amba-pl011: lock console writes against interrupts
From: Linus Walleij @ 2012-01-17 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial
Cc: linux-arm-kernel, Rabin Vincent, stable, Linus Walleij
From: Rabin Vincent <rabin.vincent@stericsson.com>
Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.
Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.
The checks for sysrq and oops_in_progress are taken
from 8250.c.
Cc: stable@kernel.org
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6958594..89178b4 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1740,9 +1740,19 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int status, old_cr, new_cr;
+ unsigned long flags;
+ int locked = 1;
clk_enable(uap->clk);
+ local_irq_save(flags);
+ if (uap->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&uap->port.lock);
+ else
+ spin_lock(&uap->port.lock);
+
/*
* First save the CR then disable the interrupts
*/
@@ -1762,6 +1772,10 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
} while (status & UART01x_FR_BUSY);
writew(old_cr, uap->port.membase + UART011_CR);
+ if (locked)
+ spin_unlock(&uap->port.lock);
+ local_irq_restore(flags);
+
clk_disable(uap->clk);
}
--
1.7.8
^ permalink raw reply related
* Re: [Qemu-devel] How can I distinguish TLB miss in MMU simulation?
From: Zhi-zhou Zhang @ 2012-01-17 10:52 UTC (permalink / raw)
To: Max Filippov; +Cc: qemu-devel
In-Reply-To: <CAMo8BfJVOCAjXBYsh_TmDv5VchanxEJ0W7G3jyz0XoqtL8R6-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Tue, Jan 17, 2012 at 4:29 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> > I'm adding a new target to qemu, now, I'm writing mmu simulation, but
> > it make me confused.
> >
> > When TLB miss occurred, I can't seperate DTLB miss from ITLB miss.
> >
> > I implemented it like this from target-xtensa:
> >
> > if (rw & 2)
> > HANDLE DTLB MISS
> > else
> > HANDLE ITLB MISS
>
> I guess that you mean qemu softmmu tlb miss, that results in a call to the
>
> void tlb_fill(CPUState *env, target_ulong vaddr, int is_write, int
> mmu_idx, void *retaddr)
>
> 'is_write' argument meaning in this call is the following: 0 -- data
> read, 1 -- data write, 2 -- instruction read.
> So, probably you should swap your DTLB and ITLB handlers.
>
> Got it, many thanks.
> > But it didn't work. May I have some suggestions?
>
> --
> Thanks.
> -- Max
>
--
Regards,
Zhizhou Zhang
[-- Attachment #2: Type: text/html, Size: 1599 bytes --]
^ permalink raw reply
* [PATCH] serial: amba-pl011: lock console writes against interrupts
From: Linus Walleij @ 2012-01-17 10:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Rabin Vincent <rabin.vincent@stericsson.com>
Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.
Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.
The checks for sysrq and oops_in_progress are taken
from 8250.c.
Cc: stable at kernel.org
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6958594..89178b4 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1740,9 +1740,19 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int status, old_cr, new_cr;
+ unsigned long flags;
+ int locked = 1;
clk_enable(uap->clk);
+ local_irq_save(flags);
+ if (uap->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&uap->port.lock);
+ else
+ spin_lock(&uap->port.lock);
+
/*
* First save the CR then disable the interrupts
*/
@@ -1762,6 +1772,10 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
} while (status & UART01x_FR_BUSY);
writew(old_cr, uap->port.membase + UART011_CR);
+ if (locked)
+ spin_unlock(&uap->port.lock);
+ local_irq_restore(flags);
+
clk_disable(uap->clk);
}
--
1.7.8
^ permalink raw reply related
* [PATCH 1/1] FIX mask to enable DJ mode
From: Nestor Lopez Casado @ 2012-01-17 10:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel, ogay,
jzanone
Cc: Nestor Lopez Casado
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
---
Hi everyone,
This is a minor bug I discovered while developing the 'soon to be posted'
driver for the Logitech Unifying Wireless Touchpad.
The user can only experience the bug if she pairs 6 devices to a Unifying
receiver. The sixth paired device would not work.
The value changed is actually a bitmask that enables reporting from each
paired device. As the sixth bit was not set, the sixth device reports are
ignored by the receiver and never get to the driver.
Jiri, this is a minor change and a real bug fix which might be posted to
stable, but as I anticipate that user impact will be really low I would say
that there is no problem on letting this fix going to your branch only.
Cheers,
Nestor
drivers/hid/hid-logitech-dj.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 38b12e4..2b56efc 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -445,7 +445,7 @@ static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
dj_report.report_id = REPORT_ID_DJ_SHORT;
dj_report.device_index = 0xFF;
dj_report.report_type = REPORT_TYPE_CMD_SWITCH;
- dj_report.report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x1F;
+ dj_report.report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
dj_report.report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] = (u8)timeout;
return logi_dj_recv_send_report(djrcv_dev, &dj_report);
}
--
1.7.5.3
^ permalink raw reply related
* Re: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
From: Mauro Carvalho Chehab @ 2012-01-17 10:49 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Hans Verkuil, Linux Media Mailing List, Rupert Eibauer,
Hans Verkuil
In-Reply-To: <Pine.LNX.4.64.1201171115300.21882@axis700.grange>
Em 17-01-2012 08:16, Guennadi Liakhovetski escreveu:
> Hi Hans
>
> On Tue, 17 Jan 2012, Hans Verkuil wrote:
>
>> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote:
>>> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote:
>>>> This is an automatic generated email to let you know that the following
>>>> patch were queued at the http://git.linuxtv.org/media_tree.git tree:
>>>>
>>>> Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
>>>> Author: Hans Verkuil <hans.verkuil@cisco.com>
>>>> Date: Wed Jan 11 07:37:54 2012 -0300
>>>
>>> [snip]
>>>
>>>> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
>>>> b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index
>>>> fd45f1c..4533068 100644
>>>> --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
>>>> +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml
>>>> @@ -61,8 +61,9 @@ desired output in an integer and call the
>>>>
>>>> <constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this
>>>> integer. Side effects are possible. For example outputs may support
>>>> different video standards, so the driver may implicitly switch the
>>>> current
>>>>
>>>> -standard. It is good practice to select an output before querying or
>>>> -negotiating any other parameters.</para>
>>>> +standard.
>>>> +standard. Because of these possible side effects applications
>>>> +must select an output before querying or negotiating any other
>>>> parameters.</para>
>>>
>>> something seems to be wrong here.
>>
>> Hi Guennadi!
>>
>> What's wrong here? I've no idea what you mean.
>
>>>> +standard.
>>>> +standard. Because of these possible side effects applications
>
> doesn't seem to make much sense?
Are you referring to grammar?
I think that a comma is missing there [1]:
Because of these possible side effects, applications
must select an output before querying or negotiating any other
parameters.
IMO, reverting the order of the explanation clause is semantically better,
as it bolds the need to select an output, and put the phrase at the
cause-effect order:
Applications must select an output before querying or negotiating
any other parameters, because of these possible side effects.
But this is really a matter of choice. In any case, except for the
comma, that makes sense for me.
[1] Rule 4 of http://grammar.ccc.commnet.edu/grammar/commas.htm
Regards,
Mauro
^ permalink raw reply
* Re: [PATCH] drm/i915: Force synchronous TLB invalidations on the BLT ring for SNB+
From: Daniel Vetter @ 2012-01-17 10:49 UTC (permalink / raw)
To: Eric Anholt; +Cc: intel-gfx
In-Reply-To: <87ehxhnj99.fsf@eliezer.anholt.net>
On Wed, Nov 09, 2011 at 12:17:06PM -0800, Eric Anholt wrote:
> On Wed, 09 Nov 2011 19:15:06 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Wed, 09 Nov 2011 10:57:00 -0800, Eric Anholt <eric@anholt.net> wrote:
> > > On Wed, 9 Nov 2011 17:32:26 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > We are advised that in order to workaround the TLB invalidation being
> > > > performed asynchronously with the command streamer that we need to use
> > > > a post-sync write along with the invalidations in the MI_FLUSH_DW so
> > > > that all operations are complete before executing the next command in
> > > > the ringbuffer.
> > > >
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=37990
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> > >
> > > I find the "References:" to a bug that this is not confirmed to fix to
> > > be very misleading.
> >
> > Because it references a bug I think is due to TLB invalidations as the
> > glitches look very similar to earlier TLB invalidation.
>
> That sort of context included with the bz reference would make me feel
> more comfortable.
What's the status of this patch? If you resend can you clarify the
bugzilla reference and also include a Bspec/PRM/whatever citation for
this workaround?
Thanks, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* [PATCH 4/4] Spawn mdmon with --initrd if mdadm was launched with --initrd
From: Jes.Sorensen @ 2012-01-17 10:48 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford, kay, harald, lpoetter, mschmidt
In-Reply-To: <1326797330-4488-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
mdadm.c | 1 +
mdadm.h | 2 ++
util.c | 17 +++++++++++++----
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/mdadm.c b/mdadm.c
index c0ccf55..3edf2f1 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -182,6 +182,7 @@ int main(int argc, char *argv[])
case InitrdOpt:
c = argv[0];
c[0] = '@';
+ __initrd = 1;
continue;
case ':':
diff --git a/mdadm.h b/mdadm.h
index d1ac1e8..fddd98d 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -1383,3 +1383,5 @@ static inline int xasprintf(char **strp, const char *fmt, ...) {
#define PROCESS_DELAYED -2
#define PROCESS_PENDING -3
+
+extern int __initrd;
diff --git a/util.c b/util.c
index 6985a70..89299b8 100644
--- a/util.c
+++ b/util.c
@@ -32,6 +32,8 @@
#include <dirent.h>
#include <signal.h>
+int __initrd;
+
/*
* following taken from linux/blkpg.h because they aren't
* anywhere else and it isn't safe to #include linux/ * stuff.
@@ -1622,10 +1624,17 @@ int start_mdmon(int devnum)
skipped = 0;
for (i=0; paths[i]; i++)
- if (paths[i][0])
- execl(paths[i], "mdmon",
- devnum2devname(devnum),
- NULL);
+ if (paths[i][0]) {
+ if (__initrd) {
+ execl(paths[i], "mdmon", "--initrd",
+ devnum2devname(devnum),
+ NULL);
+ } else {
+ execl(paths[i], "mdmon",
+ devnum2devname(devnum),
+ NULL);
+ }
+ }
exit(1);
case -1: fprintf(stderr, Name ": cannot run mdmon. "
"Array remains readonly\n");
--
1.7.8.3
^ permalink raw reply related
* [PATCH 3/4] Add --initrd argument to mdmon
From: Jes.Sorensen @ 2012-01-17 10:48 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford, kay, harald, lpoetter, mschmidt
In-Reply-To: <1326797330-4488-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
mdmon.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/mdmon.c b/mdmon.c
index a65c4a4..139bd85 100644
--- a/mdmon.c
+++ b/mdmon.c
@@ -276,6 +276,12 @@ void usage(void)
exit(2);
}
+/*
+ * Option values that don't have a short version, to avoid clashing\
+ * with ascii values
+ */
+#define INITRD_OPT 0x100
+
static int mdmon(char *devname, int devnum, int must_fork, int takeover);
int main(int argc, char *argv[])
@@ -283,6 +289,7 @@ int main(int argc, char *argv[])
char *container_name = NULL;
int devnum;
char *devname;
+ char *c;
int status = 0;
int opt;
int all = 0;
@@ -291,6 +298,7 @@ int main(int argc, char *argv[])
{"all", 0, NULL, 'a'},
{"takeover", 0, NULL, 't'},
{"help", 0, NULL, 'h'},
+ {"initrd", 0, NULL, INITRD_OPT},
{NULL, 0, NULL, 0}
};
@@ -304,6 +312,11 @@ int main(int argc, char *argv[])
container_name = optarg;
takeover = 1;
break;
+ case INITRD_OPT:
+ c = argv[0];
+ c[0] = '@';
+ continue;
+
case 'h':
default:
usage();
--
1.7.8.3
^ permalink raw reply related
* [PATCH 2/4] Add --initrd argument to mdadm
From: Jes.Sorensen @ 2012-01-17 10:48 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford, kay, harald, lpoetter, mschmidt
In-Reply-To: <1326797330-4488-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
When --initrd is parsed, mdadm will change the first character of
argv[0] to '@'. This is used to signal to systemd that mdadm was
launched from initramfs and should not be shut down before returning
to the initramfs.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
ReadMe.c | 3 +++
mdadm.c | 10 ++++++++++
mdadm.h | 1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/ReadMe.c b/ReadMe.c
index 9aa798b..49dc04f 100644
--- a/ReadMe.c
+++ b/ReadMe.c
@@ -111,6 +111,7 @@ struct option long_options[] = {
{"kill-subarray", 1, 0, KillSubarray},
{"update-subarray", 1, 0, UpdateSubarray},
{"udev-rules", 2, 0, UdevRules},
+ {"initrd", 0, 0, InitrdOpt},
/* synonyms */
{"monitor", 0, 0, 'F'},
@@ -268,6 +269,8 @@ char OptionHelp[] =
" --query -Q : Display general information about how a\n"
" device relates to the md driver\n"
" --auto-detect : Start arrays auto-detected by the kernel\n"
+" --initrd : Set first character of argv[0] to @ to indicate the\n"
+" application was launched from initrd.\n"
;
/*
"\n"
diff --git a/mdadm.c b/mdadm.c
index f07fac2..c0ccf55 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -174,6 +174,16 @@ int main(int argc, char *argv[])
homehost = optarg;
continue;
+ /*
+ * --initrd sets first char of argv[0] to @. This is used
+ * by systemd to signal that the tast was launched from
+ * initrd/initramfs and should be preserved during shutdown
+ */
+ case InitrdOpt:
+ c = argv[0];
+ c[0] = '@';
+ continue;
+
case ':':
case '?':
fputs(Usage, stderr);
diff --git a/mdadm.h b/mdadm.h
index 381ef86..d1ac1e8 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -321,6 +321,7 @@ enum special_options {
UdevRules,
FreezeReshape,
Continue,
+ InitrdOpt,
};
/* structures read from config file */
--
1.7.8.3
^ permalink raw reply related
* [PATCH 1/4] mdmon: Use getopt_long() to parse command line options
From: Jes.Sorensen @ 2012-01-17 10:48 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford, kay, harald, lpoetter, mschmidt
In-Reply-To: <1326797330-4488-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
This changes mdmon over to use getopt_long() for option parsing,
making it easier to add new options. In addition this patch introduces
a short version -t for --takeover and adds -h/--help.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
mdmon.c | 51 ++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/mdmon.c b/mdmon.c
index b6ae0e6..a65c4a4 100644
--- a/mdmon.c
+++ b/mdmon.c
@@ -265,7 +265,14 @@ static int do_fork(void)
void usage(void)
{
- fprintf(stderr, "Usage: mdmon [--all] [--takeover] CONTAINER\n");
+ fprintf(stderr,
+"Usage: mdmon [options] CONTAINER\n"
+"\n"
+"Options are:\n"
+" --help -h : This message\n"
+" --all : All devices\n"
+" --takeover -t : Takeover container\n"
+);
exit(2);
}
@@ -277,25 +284,47 @@ int main(int argc, char *argv[])
int devnum;
char *devname;
int status = 0;
- int arg;
+ int opt;
int all = 0;
int takeover = 0;
-
- for (arg = 1; arg < argc; arg++) {
- if (strncmp(argv[arg], "--all",5) == 0 ||
- strcmp(argv[arg], "/proc/mdstat") == 0) {
- container_name = argv[arg];
+ static struct option options[] = {
+ {"all", 0, NULL, 'a'},
+ {"takeover", 0, NULL, 't'},
+ {"help", 0, NULL, 'h'},
+ {NULL, 0, NULL, 0}
+ };
+
+ while ((opt = getopt_long(argc, argv, "th", options, NULL)) != -1) {
+ switch (opt) {
+ case 'a':
+ container_name = argv[optind-1];
all = 1;
- } else if (strcmp(argv[arg], "--takeover") == 0)
+ break;
+ case 't':
+ container_name = optarg;
takeover = 1;
- else if (container_name == NULL)
- container_name = argv[arg];
- else
+ break;
+ case 'h':
+ default:
usage();
+ break;
+ }
}
+
+ if (all == 0 && container_name == NULL) {
+ if (argv[optind])
+ container_name = argv[optind];
+ }
+
if (container_name == NULL)
usage();
+ if (argc - optind > 1)
+ usage();
+
+ if (strcmp(container_name, "/proc/mdstat") == 0)
+ all = 1;
+
if (all) {
struct mdstat_ent *mdstat, *e;
int container_len = strlen(container_name);
--
1.7.8.3
^ permalink raw reply related
* [PATCH 0/4] add --initrd argument to mdadm/mdmon
From: Jes.Sorensen @ 2012-01-17 10:48 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford, kay, harald, lpoetter, mschmidt
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
In order to resolve the problem with reboots hanging on systems with /
on an IMSM RAID, systemd needs to be able to see that a given mdadm
and mdmon process was launched from the initramfs, and allow it to
survive until it gets back to there, so it can unmount the root
filesystem safely.
These patches introduces the --initrd argument to mdadm which makes it
change the first character of argv[0] to '@' to match the convention
set by systemd.
In addition I also changed mdmon to use getopt_long to make it easier
to add more command line arguments to it. Note that I went through
great effort to preserve the behavior, even though the old code did
some somewhat dodgy stuff using changing the arvg buffer pointing to
the '--all' argument.
Comments?
Thanks,
Jes
Jes Sorensen (4):
mdmon: Use getopt_long() to parse command line options
Add --initrd argument to mdadm
Add --initrd argument to mdmon
Spawn mdmon with --initrd if mdadm was launched with --initrd
ReadMe.c | 3 ++
mdadm.c | 11 ++++++++++
mdadm.h | 3 ++
mdmon.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++----------
util.c | 17 ++++++++++++---
5 files changed, 83 insertions(+), 15 deletions(-)
--
1.7.8.3
^ permalink raw reply
* Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
From: Eric Dumazet @ 2012-01-17 10:47 UTC (permalink / raw)
To: Štefan Gula
Cc: Alexey Kuznetsov, David S. Miller, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CAGsizzLwCTpuZsZyx24T9WZy1DSJo+rfhDxLsE8UmeZOSxw+mA@mail.gmail.com>
Le mardi 17 janvier 2012 à 11:43 +0100, Štefan Gula a écrit :
> ok maybe I am getting it wrong, but I am little bit stuck here. I
> recheck the original bridge code. The difference I recognize is that
> in bridge code function:
> br_fdb_init() and br_fdb_fini()
> are called from module init and module exit functions:
> br_init and br_deinit
>
> in my code they are called from functions:
> ipgre_init_net and ipgre_exit_net
> instead of:
> ipgre_init and ipgre_fini
>
> To be honest I am not so familiar enough with kernel structure that I
> see the difference on the first time. But I think that with your help
> it can be done easily. The main idea was to create hash-table that is
> used to determine the destination IPv4 address (part of the entry
> structure). That hash-table should be different per each gretap
> interface - I think that's the reason why I put those init and fini
> inside ipgre_init_net and ipgre_exit_net. Am I right that the
> placement of this calls is correct or not? If not where those calls
> should be placed?
>
> On the other hand I have no idea how to substitute those two function
> with a code that you are suggesting kmalloc()/kfree(). I would be glad
> if you can help me here by providing me example how to substitute
> those two functions with kmalloc/kfree for the future usage (I am more
> reverse engineer learner type of person than manuals reading one)
Something like the following ?
Note : I also put the "orig_source = iph->saddr;"
_after_ "iph = ip_hdr(skb);"
iph = ip_hdr(skb);
#ifdef CONFIG_NET_IPGRE_BRIDGE
orig_source = iph->saddr;
#endif
diff --git a/include/net/ipip.h b/include/net/ipip.h
index a32654d..6a06fc2 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ -27,6 +27,14 @@ struct ip_tunnel {
__u32 o_seqno; /* The last output seqno */
int hlen; /* Precalculated GRE header length */
int mlink;
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+#define GRETAP_BR_HASH_BITS 8
+#define GRETAP_BR_HASH_SIZE (1 << GRETAP_BR_HASH_BITS)
+ struct hlist_head hash[GRETAP_BR_HASH_SIZE];
+ spinlock_t hash_lock;
+ unsigned long ageing_time;
+ struct timer_list gc_timer;
+#endif
struct ip_tunnel_parm parms;
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 1a8f93b..5b320a3 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -211,6 +211,15 @@ config NET_IPGRE_BROADCAST
Network), but can be distributed all over the Internet. If you want
to do that, say Y here and to "IP multicast routing" below.
+config NET_IPGRE_BRIDGE
+ bool "IP: Ethernet over multipoint GRE over IP"
+ depends on IP_MULTICAST && NET_IPGRE && NET_IPGRE_BROADCAST
+ help
+ Allows you to use multipoint GRE VPN as virtual switch and interconnect
+ several L2 endpoints over L3 routed infrastructure. It is useful for
+ creating multipoint L2 VPNs which can be later used inside bridge
+ interfaces If you want to use. GRE multipoint L2 VPN feature say Y.
+
config IP_MROUTE
bool "IP: multicast routing"
depends on IP_MULTICAST
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 2b53a1f..df22565 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -52,6 +52,11 @@
#include <net/ip6_route.h>
#endif
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+#include <linux/jhash.h>
+#include <asm/unaligned.h>
+#endif
+
/*
Problems & solutions
--------------------
@@ -134,6 +139,172 @@ struct ipgre_net {
struct net_device *fb_tunnel_dev;
};
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ /*
+ * This part of code includes codes to enable L2 ethernet
+ * switch virtualization over IP routed infrastructure with
+ * utilization of multicast capable endpoint using Ethernet
+ * over GRE
+ *
+ * Author: Stefan Gula
+ * Signed-off-by: Stefan Gula <steweg@gmail.com>
+ */
+struct ipgre_tap_bridge_entry {
+ struct hlist_node hlist;
+ __be32 raddr;
+ unsigned char addr[ETH_ALEN];
+ unsigned long updated;
+ struct rcu_head rcu;
+};
+
+static u32 ipgre_salt __read_mostly;
+
+static inline int ipgre_tap_bridge_hash(const unsigned char *mac)
+{
+ u32 key = get_unaligned((u32 *)(mac + 2));
+
+ return jhash_1word(key, ipgre_salt) & (GRETAP_BR_HASH_SIZE - 1);
+}
+
+static inline int ipgre_tap_bridge_has_expired(const struct ip_tunnel *tunnel,
+ const struct ipgre_tap_bridge_entry *entry)
+{
+ return time_before_eq(entry->updated + tunnel->ageing_time,
+ jiffies);
+}
+
+static inline void ipgre_tap_bridge_delete(struct ipgre_tap_bridge_entry *entry)
+{
+ hlist_del_rcu(&entry->hlist);
+ kfree_rcu(entry, rcu);
+}
+
+static void ipgre_tap_bridge_cleanup(unsigned long _data)
+{
+ struct ip_tunnel *tunnel = (struct ip_tunnel *)_data;
+ unsigned long delay = tunnel->ageing_time;
+ unsigned long next_timer = jiffies + tunnel->ageing_time;
+ int i;
+
+ spin_lock(&tunnel->hash_lock);
+ for (i = 0; i < GRETAP_BR_HASH_SIZE; i++) {
+ struct ipgre_tap_bridge_entry *entry;
+ struct hlist_node *h, *n;
+
+ hlist_for_each_entry_safe(entry, h, n,
+ &tunnel->hash[i], hlist)
+ {
+ unsigned long this_timer;
+ this_timer = entry->updated + delay;
+ if (time_before_eq(this_timer, jiffies))
+ ipgre_tap_bridge_delete(entry);
+ else if (time_before(this_timer, next_timer))
+ next_timer = this_timer;
+ }
+ }
+ spin_unlock(&tunnel->hash_lock);
+ mod_timer(&tunnel->gc_timer, round_jiffies_up(next_timer));
+}
+
+static void ipgre_tap_bridge_flush(struct ip_tunnel *tunnel)
+{
+ int i;
+
+ spin_lock_bh(&tunnel->hash_lock);
+ for (i = 0; i < GRETAP_BR_HASH_SIZE; i++) {
+ struct ipgre_tap_bridge_entry *entry;
+ struct hlist_node *h, *n;
+
+ hlist_for_each_entry_safe(entry, h, n,
+ &tunnel->hash[i], hlist)
+ {
+ ipgre_tap_bridge_delete(entry);
+ }
+ }
+ spin_unlock_bh(&tunnel->hash_lock);
+}
+
+static struct ipgre_tap_bridge_entry *__ipgre_tap_bridge_get(
+ struct ip_tunnel *tunnel, const unsigned char *addr)
+{
+ struct hlist_node *h;
+ struct ipgre_tap_bridge_entry *entry;
+
+ hlist_for_each_entry_rcu(entry, h,
+ &tunnel->hash[ipgre_tap_bridge_hash(addr)], hlist) {
+ if (!compare_ether_addr(entry->addr, addr)) {
+ if (unlikely(ipgre_tap_bridge_has_expired(tunnel,
+ entry)))
+ break;
+ return entry;
+ }
+ }
+
+ return NULL;
+}
+
+static struct ipgre_tap_bridge_entry *ipgre_tap_bridge_find(
+ struct hlist_head *head,
+ const unsigned char *addr)
+{
+ struct hlist_node *h;
+ struct ipgre_tap_bridge_entry *entry;
+
+ hlist_for_each_entry(entry, h, head, hlist) {
+ if (!compare_ether_addr(entry->addr, addr))
+ return entry;
+ }
+ return NULL;
+}
+
+
+static struct ipgre_tap_bridge_entry *ipgre_tap_bridge_find_rcu(
+ struct hlist_head *head,
+ const unsigned char *addr)
+{
+ struct hlist_node *h;
+ struct ipgre_tap_bridge_entry *entry;
+
+ hlist_for_each_entry_rcu(entry, h, head, hlist) {
+ if (!compare_ether_addr(entry->addr, addr))
+ return entry;
+ }
+ return NULL;
+}
+
+static struct ipgre_tap_bridge_entry *ipgre_tap_bridge_create(
+ struct hlist_head *head,
+ u32 source,
+ const unsigned char *addr)
+{
+ struct ipgre_tap_bridge_entry *entry;
+
+ entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ if (entry) {
+ memcpy(entry->addr, addr, ETH_ALEN);
+ entry->raddr = source;
+ entry->updated = jiffies;
+ hlist_add_head_rcu(&entry->hlist, head);
+ }
+ return entry;
+}
+
+static __be32 ipgre_tap_bridge_get_raddr(struct ip_tunnel *tunnel,
+ const unsigned char *addr)
+{
+ __be32 raddr = 0;
+ struct ipgre_tap_bridge_entry *entry;
+
+ rcu_read_lock();
+ entry = __ipgre_tap_bridge_get(tunnel, addr);
+ if (entry)
+ raddr = entry->raddr;
+ rcu_read_unlock();
+
+ return raddr;
+}
+
+#endif
/* Tunnel hash table */
/*
@@ -562,6 +733,12 @@ static int ipgre_rcv(struct sk_buff *skb)
struct ip_tunnel *tunnel;
int offset = 4;
__be16 gre_proto;
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ __be32 orig_source;
+ struct hlist_head *head;
+ struct ipgre_tap_bridge_entry *entry;
+ const struct ethhdr *tethhdr;
+#endif
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -659,10 +836,38 @@ static int ipgre_rcv(struct sk_buff *skb)
tunnel->dev->stats.rx_errors++;
goto drop;
}
-
iph = ip_hdr(skb);
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ orig_source = iph->saddr;
+#endif
skb->protocol = eth_type_trans(skb, tunnel->dev);
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ if (ipv4_is_multicast(tunnel->parms.iph.daddr)) {
+ tethhdr = eth_hdr(skb);
+ if (!is_multicast_ether_addr(
+ tethhdr->h_source)) {
+ head = &tunnel->hash[
+ ipgre_tap_bridge_hash(
+ tethhdr->h_source)];
+ entry = ipgre_tap_bridge_find_rcu(head,
+ tethhdr->h_source);
+ if (likely(entry)) {
+ entry->raddr = orig_source;
+ entry->updated = jiffies;
+ } else {
+ spin_lock(&tunnel->hash_lock);
+ if (!ipgre_tap_bridge_find(head,
+ tethhdr->h_source))
+ ipgre_tap_bridge_create(
+ head,
+ orig_source,
+ tethhdr->h_source);
+ spin_unlock(&tunnel->hash_lock);
+ }
+ }
+ }
+#endif
}
tstats = this_cpu_ptr(tunnel->dev->tstats);
@@ -702,7 +907,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
struct iphdr *iph; /* Our new IP header */
unsigned int max_headroom; /* The extra header space needed */
int gre_hlen;
- __be32 dst;
+ __be32 dst = 0;
int mtu;
if (dev->type == ARPHRD_ETHER)
@@ -716,7 +921,15 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
tiph = &tunnel->parms.iph;
}
- if ((dst = tiph->daddr) == 0) {
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ if ((dev->type == ARPHRD_ETHER) &&
+ ipv4_is_multicast(tunnel->parms.iph.daddr))
+ dst = ipgre_tap_bridge_get_raddr(tunnel,
+ ((struct ethhdr *)skb->data)->h_dest);
+#endif
+ if (dst == 0)
+ dst = tiph->daddr;
+ if (dst == 0) {
/* NBMA tunnel */
if (skb_dst(skb) == NULL) {
@@ -1211,6 +1424,16 @@ static int ipgre_open(struct net_device *dev)
return -EADDRNOTAVAIL;
t->mlink = dev->ifindex;
ip_mc_inc_group(__in_dev_get_rtnl(dev), t->parms.iph.daddr);
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ if (t->dev->type == ARPHRD_ETHER) {
+ INIT_HLIST_HEAD(t->hash);
+ spin_lock_init(&t->hash_lock);
+ t->ageing_time = 300 * HZ;
+ setup_timer(&t->gc_timer, ipgre_tap_bridge_cleanup,
+ (unsigned long) t);
+ mod_timer(&t->gc_timer, jiffies + t->ageing_time);
+ }
+#endif
}
return 0;
}
@@ -1221,6 +1444,12 @@ static int ipgre_close(struct net_device *dev)
if (ipv4_is_multicast(t->parms.iph.daddr) && t->mlink) {
struct in_device *in_dev;
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ if (t->dev->type == ARPHRD_ETHER) {
+ ipgre_tap_bridge_flush(t);
+ del_timer_sync(&t->gc_timer);
+ }
+#endif
in_dev = inetdev_by_index(dev_net(dev), t->mlink);
if (in_dev)
ip_mc_dec_group(in_dev, t->parms.iph.daddr);
@@ -1707,6 +1936,9 @@ static int __init ipgre_init(void)
printk(KERN_INFO "GRE over IPv4 tunneling driver\n");
+#ifdef CONFIG_NET_IPGRE_BRIDGE
+ get_random_bytes(&ipgre_salt, sizeof(ipgre_salt));
+#endif
err = register_pernet_device(&ipgre_net_ops);
if (err < 0)
return err;
^ permalink raw reply related
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.