Ingo, et al.-
Ok, sorry for the delay, here are the test results you've been asking
for.
First, some information about what I did. I attached the module that I ran this
test with at the bottom of this email. You'll note that I started using a
module parameter write patch to trigger th
On Mon, Oct 28, 2013 at 05:24:38PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > Looking at the specific cpu counters we get this:
> >
> > Base:
> > Total time: 0.179 [sec]
> >
> > Performance counter stats for 'perf bench sc
On Mon, Oct 28, 2013 at 05:20:45PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > Base:
> >0.093269042 seconds time elapsed
> > ( +- 2.24% )
> > Prefetch (5x64):
> >
On Mon, Oct 28, 2013 at 01:46:30PM -0400, Neil Horman wrote:
> On Mon, Oct 28, 2013 at 05:24:38PM +0100, Ingo Molnar wrote:
> >
> > * Neil Horman wrote:
> >
> > > Looking at the specific cpu counters we get this:
> > >
> > > Base:
> > &g
On Tue, Oct 29, 2013 at 09:25:42AM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > Heres my data for running the same test with taskset restricting
> > execution to only cpu0. I'm not quite sure whats going on here,
> > but doing so resulted in a 10x
cts attached.
>
> Also, remove the same functionality from populate_msi_sysfs(), cause on
> failure we anyway call free_msi_irqs(), which will take care of all the
> kobjects properly.
>
> And add the forgotten pci_dev_put(pdev) in case of failure to register the
> kobje
dev, and is
> not a user of it.
>
> CC: Bjorn Helgaas
> CC: Neil Horman
> CC: Greg Kroah-Hartman
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Veaceslav Falico
Acked-by: Neil Horman
>
--
To unsubscribe from this list: send the li
we've
> failed to allocate irqs and try it again.
>
> To fix that, move the unregister part to free_msi_irqs() and remove already
> existing ones. Also, verify if it was actually created - we don't always
> call free_msi_irqs() after populate_msi_sysfs().
>
> CC: Bj
On Tue, Oct 29, 2013 at 12:30:31PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > Sure it was this:
> > for i in `seq 0 1 3`
> > do
> > echo $i > /sys/module/csum_test/parameters/module_test_mode
> > taskset -c 0 perf stat --repeat 20 -C 0 -dd
On Tue, Oct 29, 2013 at 01:52:33PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > On Tue, Oct 29, 2013 at 12:30:31PM +0100, Ingo Molnar wrote:
> > >
> > > * Neil Horman wrote:
> > >
> > > > Sure it was this:
> > >
On Tue, Oct 29, 2013 at 02:11:49PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > I'm sure it worked properly on my system here, I specificially
> > checked it, but I'll gladly run it again. You have to give me an
> > hour as I have a mee
On Tue, Oct 29, 2013 at 02:11:49PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > I'm sure it worked properly on my system here, I specificially
> > checked it, but I'll gladly run it again. You have to give me an
> > hour as I have a mee
On Tue, Oct 29, 2013 at 03:27:16PM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > So, I apologize, you were right. I was running the test.sh script
> > but perf was measuring itself. [...]
>
> Ok, cool - one mystery less!
>
> > Which overall loo
On Wed, Oct 30, 2013 at 01:25:39AM -0400, Doug Ledford wrote:
> * Neil Horman wrote:
> > 3) The run times are proportionally larger, but still indicate that
> > Parallel ALU
> > execution is hurting rather than helping, which is counter-intuitive. I'm
> > lookin
On Wed, Oct 30, 2013 at 09:35:05AM -0400, Doug Ledford wrote:
> On 10/30/2013 07:02 AM, Neil Horman wrote:
>
> >That does makes sense, but it then begs the question, whats the advantage of
> >having multiple alu's at all?
>
> There's lots of ALU operations
On Thu, Oct 31, 2013 at 11:22:00AM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > > etc. For such short runtimes make sure the last column displays
> > > close to 100%, so that the PMU results become trustable.
> > >
> > > A nehalem
On Wed, Oct 30, 2013 at 09:35:05AM -0400, Doug Ledford wrote:
> On 10/30/2013 07:02 AM, Neil Horman wrote:
>
> >That does makes sense, but it then begs the question, whats the advantage of
> >having multiple alu's at all?
>
> There's lots of ALU operations
On Fri, Nov 01, 2013 at 10:13:37AM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > On Thu, Oct 31, 2013 at 11:22:00AM +0100, Ingo Molnar wrote:
> > >
> > > * Neil Horman wrote:
> > >
> > > > > etc. For such short runtimes m
On Fri, Nov 01, 2013 at 03:42:46PM +, Ben Hutchings wrote:
> On Thu, 2013-10-31 at 14:30 -0400, Neil Horman wrote:
> [...]
> > It
> > functions, but unfortunately the performance lost to the completely broken
> > branch prediction that this inflict
On Fri, Nov 01, 2013 at 04:18:50PM -, David Laight wrote:
> > How would you suggest replacing the jumps in this case? I agree it would be
> > faster here, but I'm not sure how I would implement an increment using a
> > single
> > conditional move.
>
> I think you need 3 instructions, move a
f the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily
Signed-off-by: Neil Horman
CC: Vlad Yasevich
CC: David Miller
CC: Greg Kroah-Hartman
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
--
To unsubscribe from
sctp has several points in its setsockopt path in which it issues deprecation
warnings. It seems like it might be handy to macrotize such a warning so other
subsystems can use it easily
Signed-off-by: Neil Horman
CC: Greg Kroah-Hartman
CC: "David S. Miller"
CC: linux-kernel@vger.
On Mon, Dec 16, 2013 at 09:50:01AM -0800, Joe Perches wrote:
> (adding Andrew Morton to cc's)
>
> On Mon, 2013-12-16 at 12:06 -0500, Neil Horman wrote:
> > sctp has several points in its setsockopt path in which it issues
> > deprecation
> > warnings. It
On Tue, Sep 16, 2014 at 04:29:23PM -0400, David Miller wrote:
> From: Neil Horman
> Date: Tue, 16 Sep 2014 06:17:04 -0400
>
> > I'm guessing the above change has uncovered another bug,
>
> Neil, read your patch carefully, I think it added the bug.
>
> The ->p
On Wed, Sep 17, 2014 at 03:43:54PM +0300, mr...@linux.ee wrote:
> > Shit, you're right, sorry about that. Its odd, I'm running it here, and
> > its not
> > causing problems, but thats obviously wrong. Meelis, please add the above
> > fix
> > to your test and confirm that it sovles the problem.
mapping
failure to prevent leaks.
Signed-off-by: Neil Horman
CC: Linux Kernel list
CC: "David S. Miller"
CC: Meelis Roos
Tested-by: Meelis Roos
---
drivers/net/ethernet/3com/3c59x.c | 50 ---
1 file changed, 41 insertions(+), 9 deletions(-)
di
sults in lost
connections.
Signed-off-by: Neil Horman
CC: Linux Kernel list
CC: "David S. Miller"
CC: Meelis Roos
Tested-by: Meelis Roos
---
drivers/net/ethernet/3com/3c59x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c
On Fri, Sep 19, 2014 at 04:29:19PM -0400, David Miller wrote:
> From: Neil Horman
> Date: Wed, 17 Sep 2014 09:04:44 -0400
>
> > Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
> > ability to unmap fragments when a single map fails in the midd
ded complexity is
> simply not justifiable.
>
> As a first step to drop cgroup module support, this patch changes the
> two config options to bool from tristate and drops module related code
> from the two controllers.
>
> Signed-off-by: Tejun Heo
> Cc: Neil Horman
> Cc:
> Cc: Peter Zijlstra
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
> Cc: Aristeu Rozanski
> Cc: Serge E. Hallyn
> Cc: "Rafael J. Wysocki"
> Cc: Vivek Goyal
> Cc: Neil Horman
> Cc: Thomas
On Wed, Sep 24, 2014 at 09:30:21AM +, Sylvain 'ythier' Hitier wrote:
> Author: Sylvain "ythier" Hitier
> Date: Wed Sep 24 09:22:16 2014 +
>
> 3c59x: fix bad split of cpu_to_le32(pci_map_single())
>
> Change the #else branch like the #if DO_ZEROCOPY branch was change
On Wed, Sep 24, 2014 at 09:30:21AM +, Sylvain 'ythier' Hitier wrote:
> Author: Sylvain "ythier" Hitier
> Date: Wed Sep 24 09:22:16 2014 +
>
> 3c59x: fix bad split of cpu_to_le32(pci_map_single())
>
> Change the #else branch like the #if DO_ZEROCOPY branch was change
On Thu, Sep 25, 2014 at 03:15:19PM +, Sylvain 'ythier' Hitier wrote:
> Hello,
>
> When: 2014-09-24_3@06-16-47 -0400
> Who: Neil Horman
> What:
> > You do probably want to fixup
> > the changelog to be a bit more clear as to whats going on here.
>
thon-T] (rev 78) in one server and 3Com Corporation 3c905C-TX/TX-M
> [Tornado] (rev 78) in the other server). Bisect leads to the following
> commit:
>
> 98ea232cf63961fad734cc8c5e07e8915ec73073 is the first bad commit
> commit 98ea232cf63961fad734cc8c5e07e8915ec73073
> Author: Ne
it:
> > >
> > > 98ea232cf63961fad734cc8c5e07e8915ec73073 is the first bad commit
> > > commit 98ea232cf63961fad734cc8c5e07e8915ec73073
> > > Author: Neil Horman
> > > Date: Thu Sep 4 06:13:38 2014 -0400
> > >
> > > 3c59x
mapping
failure to prevent leaks.
Please test this patch out. It may fix the problem your experiencing, and, if
you enable dynamic debug in the driver, it will certainly confirm that is the
problem you are experiencing.
Signed-off-by: Neil Horman
---
drivers/net/ethernet/3com/3c59x.c | 50
; Signed-off-by: Xufeng Zhang
Acked-by: Neil Horman
> ---
> net/sctp/socket.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9e91d6e..699ae1e 100644
> --- a/net/sctp/socket.c
>
gt; Cc: Vivek Goyal
> Cc: Jens Axboe
> Cc: Li Zefan
> Cc: Peter Zijlstra
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Neil Horman
> Cc: "David S. Miller"
> ---
> block/blk-cgroup.h | 2 +-
> include/linux/cgroup.h | 29 +++
On Tue, Apr 08, 2014 at 09:56:10AM +0200, Gerhard Sittig wrote:
> [ removed cscope-devel from Cc:, non-subscriber mails get blocked anyway ]
>
> On Mon, 2014-04-07 at 14:42 +0200, Gerhard Sittig wrote:
> >
> > On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote:
> &
On Mon, Mar 24, 2014 at 12:42:46AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
>
> The rcu_assign_pointer() ensures that the initialization of a structure
> is carried out before storing a pointer to that structure.
> And in
On Mon, Mar 24, 2014 at 01:01:04AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
>
> The rcu_assign_pointer() ensures that the initialization of a structure
> is carried out before storing a pointer to that structure.
> And in
On Mon, Mar 24, 2014 at 06:14:35AM -0700, Eric Dumazet wrote:
> On Mon, 2014-03-24 at 07:11 -0400, Neil Horman wrote:
> > On Mon, Mar 24, 2014 at 12:42:46AM +0530, Monam Agarwal wrote:
> > > This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
> >
On Tue, Jun 17, 2014 at 04:05:07PM -0400, Neil Horman wrote:
> Just a few little fixups for tmon, to prevent abuse of its logging facility
>
> Best
> Neil
>
Ping, Zhang, Jacob acked these, but I've not seen them go into your tree yet.
Do you have an issue with them?
Neil
&
On Tue, Jul 01, 2014 at 09:49:25PM +0800, Zhang Rui wrote:
> On Tue, 2014-07-01 at 07:42 -0400, Neil Horman wrote:
> > On Tue, Jun 17, 2014 at 04:05:07PM -0400, Neil Horman wrote:
> > > Just a few little fixups for tmon, to prevent abuse of its logging
> > > facility
&
name.
>
> Signed-off-by: Tejun Heo
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Li Zefan
> Cc: Vivek Goyal
> Cc: Peter Zijlstra
> Cc: Paul Mackerras
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Aristeu Rozanski
> Cc: Neil Horman
> Cc:
round cgroup_add_cftypes() and replaces
> all cgroup_add_cftypes() usages with it.
>
> While at it, this patch drops a completely spurious return from
> __hugetlb_cgroup_file_init().
>
> This patch doesn't introduce any functional differences.
>
> Signed-off-by: Tej
hy" is noop now as the whole
> array isn't used on the default hierarchy. The flag is removed.
>
> Signed-off-by: Tejun Heo
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Li Zefan
> Cc: Vivek Goyal
> Cc: Peter Zijlstra
> Cc: Paul Mackerras
> Cc: Ingo M
> v2: remove extraneous blank line, perform checks in static inline
> function, drop no longer necessary fips.h include.
>
> CC: Herbert Xu
> CC: "David S. Miller"
> CC: Rusty Russell
> CC: Stephan Mueller
> CC: linux-cry...@vger.kernel.org
> Signed-off-by:
40.800441] Core dump to |/foobar12345 lpq83 lpq83 lpq83 lpq83 lpq83
> lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83
> lpq83 lpq83 lpq83 pipe failed
>
> Fixes: 5fe9d8ca21cc ("coredump: cn_vprintf() has no reason to call
> vsnprintf() twice")
>
On Tue, Apr 22, 2014 at 01:31:16PM +0800, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign
On Tue, Apr 22, 2014 at 01:32:02PM +0800, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign
oup->id;
> + void *v = (void *)(unsigned long)css_to_id(css);
>
> cgroup_taskset_for_each(p, tset) {
> task_lock(p);
> --
> 2.0.0-rc0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body
On Tue, Jun 10, 2014 at 02:27:07PM +0800, Xufeng Zhang wrote:
> Hi Vlad and Neil,
>
> I found a sk_ack_backlog wrap-around problem during handling received
> COOKIE_ECHO.
>
> Consider the scenario:
> For a TCP-style socket, while processing the COOKIE_ECHO chunk in
> sctp_sf_do_5_1D_ce(),
> after
On Mon, Mar 31, 2014 at 09:45:43PM +0200, Thomas Gleixner wrote:
> On Mon, 31 Mar 2014, Linus Torvalds wrote:
>
> > On Mon, Mar 31, 2014 at 7:49 AM, Ingo Molnar wrote:
> > > Neil Horman (1):
> > > x86: Adjust irq remapping quirk for older revision
from
> "make cscope tags TAGS" is the same with and without this patch: it doesn't
> seems to introduce any regression (on Fedora 20).
>
> Link: http://lkml.kernel.org/r/1396530975.4361.28.camel@localhost.localdomain
> Link: http://mid.gmane.org/534312f8.5090...@t-o
hile (msi_attrs[count]) {
> dev_attr = container_of(msi_attrs[count],
> struct device_attribute, attr);
> kfree(dev_attr->attr.name);
> --
> 1.7.9.5
>
>
Acked-by: Neil Horman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jun 16, 2014 at 11:05:57AM -0700, Cong Wang wrote:
> On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
> wrote:
> > Hi,
> >
> > i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
> >
> > netconsole is used with vmbr0 (bridge) which is on top of bond0.
> >
> >
On Tue, Jun 17, 2014 at 08:06:58AM +0200, Stefan Priebe - Profihost AG wrote:
> Am 16.06.2014 23:30, schrieb Francois Romieu:
> > Stefan Priebe - Profihost AG :
> > [...]
> >> That sounds great! Is there anything I can do or some code I can port to
> >> veth?
> >
> > You may add an empty handler
current, the tmon umask value is set to 0, which mean whatever the permission
mask in the shell are when starting tmon in daemon mode are what the permissions
of any created files will be. We should likely set something more explicit, so
lets go with the usual 022
Signed-off-by: Neil Horman
CC
igned-off-by: Neil Horman
CC: Zhang Rui
CC: Jacob Pan
---
tools/thermal/tmon/tmon.c | 24
1 file changed, 24 insertions(+)
diff --git a/tools/thermal/tmon/tmon.c b/tools/thermal/tmon/tmon.c
index b30f531..059e0be 100644
--- a/tools/thermal/tmon/tmon.c
+++ b/tools/thermal
Just a few little fixups for tmon, to prevent abuse of its logging facility
Best
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
struct gets freed. Ensure that we cancel it prior to freeing the rport
Signed-off-by: Neil Horman
CC: "James E.J. Bottomley"
CC: Christoph Hellwig
CC: linux-s...@vger.kernel.org
CC: Robert Love
CC: Vasu Dev
---
drivers/scsi/scsi_transport_fc.c | 1 +
1 file changed, 1 insertio
the function
where we are sure we won't preempt or sleep. This also allows us to not have to
enable pre-emption when doing a per-cpu lookup, since we're certain not to get
rescheduled.
Signed-off-by: Neil Horman
CC: "James E.J. Bottomley"
CC: Christoph Hellwig
CC: linux-s..
On Fri, Oct 18, 2013 at 02:15:52PM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-18 at 16:11 -0400, Neil Horman wrote:
>
> > #define BUFSIZ_ORDER 4
> > #define BUFSIZ ((2 << BUFSIZ_ORDER) * (1024*1024*2))
> > static int __init csum_init_module(void)
> > {
&
On Mon, Oct 21, 2013 at 10:31:38AM -0700, Eric Dumazet wrote:
> On Sun, 2013-10-20 at 17:29 -0400, Neil Horman wrote:
> > On Fri, Oct 18, 2013 at 02:15:52PM -0700, Eric Dumazet wrote:
> > > On Fri, 2013-10-18 at 16:11 -0400, Neil Horman wrote:
> > >
> > > >
On Fri, Oct 18, 2013 at 02:15:52PM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-18 at 16:11 -0400, Neil Horman wrote:
>
> > #define BUFSIZ_ORDER 4
> > #define BUFSIZ ((2 << BUFSIZ_ORDER) * (1024*1024*2))
> > static int __init csum_init_module(void)
> > {
&
On Mon, Oct 21, 2013 at 12:44:05PM -0700, Eric Dumazet wrote:
> On Mon, 2013-10-21 at 15:21 -0400, Neil Horman wrote:
>
> >
> > Ok, so I ran the above code on a single cpu using taskset, and set irq
> > affinity
> > such that no interrupts (save for local
On Fri, Oct 18, 2013 at 10:09:54AM -0700, H. Peter Anvin wrote:
> If implemented properly adcx/adox should give additional speedup... that is
> the whole reason for their existence.
>
Ok, fair enough. Unfotunately, I'm not going to be able to get my hands on a
stepping of this CPU to test any co
On Sat, Oct 26, 2013 at 02:01:08PM +0200, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > On Mon, Oct 21, 2013 at 12:44:05PM -0700, Eric Dumazet wrote:
> > > On Mon, 2013-10-21 at 15:21 -0400, Neil Horman wrote:
> > >
> > > >
> > > >
On Sun, Oct 27, 2013 at 08:26:32AM +0100, Ingo Molnar wrote:
>
> * Neil Horman wrote:
>
> > > You keep ignoring my request to calculate and account for noise of the
> > > measurement.
> >
> > Don't confuse "ignoring" with "haven
sctp has several points in its setsockopt path in which it issues deprecation
warnings. It seems like it might be handy to macrotize such a warning so other
subsystems can use it easily
Signed-off-by: Neil Horman
CC: Greg Kroah-Hartman
CC: "David S. Miller"
CC: linux-kernel@vger.
f the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily
Signed-off-by: Neil Horman
CC: Vlad Yasevich
CC: David Miller
CC: Greg Kroah-Hartman
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
Change note
On Wed, Nov 13, 2013 at 10:09:51AM -, David Laight wrote:
> > Sure, I modified the code so that we only prefetched 2 cache lines ahead,
> > but
> > only if the overall length of the input buffer is more than 2 cache lines.
> > Below are the results (all counts are the average of 100 iterat
On Wed, Nov 13, 2013 at 01:32:50PM -, David Laight wrote:
> > > I'm not sure, whats the typical capacity for the branch predictors
> > > ability to remember code paths?
> ...
> >
> > For such simple single-target branches it goes near or over a thousand for
> > recent Intel and AMD microarchit
On Thu, Nov 14, 2013 at 12:33:11PM -0700, Bjorn Helgaas wrote:
> On Tue, Nov 5, 2013 at 11:55 AM, Bjorn Helgaas wrote:
> > On Sat, Nov 2, 2013 at 9:50 AM, Greg Kroah-Hartman
> > wrote:
> >> On Fri, Nov 01, 2013 at 05:40:02PM -0600, Bjorn Helgaas wrote:
> >>> On Tue, Oct 29, 2013 at 3:46 PM, Greg
On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
> On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
> >Expected Behavior:
> >When hearing an ack from a tranport/path, set its state to normal/on if it's
> >in abnormal(__partial_failure__ or inactive) state.
> >
> >state machine of tranp
On Fri, Nov 15, 2013 at 09:00:58AM -0500, Vlad Yasevich wrote:
> On 11/15/2013 07:30 AM, Neil Horman wrote:
> >On Thu, Nov 14, 2013 at 09:34:55PM -0500, Vlad Yasevich wrote:
> >>On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
> >>>Expected Behavior:
> >>&g
ded value
> for Path.Max.Retrans in the standard is 5"?
>
pathmaxrtx is initalized to 5 in sctp_init_sock, so we're in compliance with the
RFC hre.
> Thanks!
>
> On 11/15/2013 03:56 PM, Neil Horman wrote:
> >On Fri, Nov 15, 2013 at 09:00:58AM -0500, Vlad Yasevich wr
On Tue, Dec 31, 2013 at 02:00:00PM -0500, David Miller wrote:
> From: Neil Horman
> Date: Mon, 23 Dec 2013 08:29:41 -0500
>
> > The SCTP protocol has several deprecation warnings in its setsockopt path
> > that
> > can be triggered by unprivlidged users. Sinc
et could not be forwarded to macvtap device. Another problem
> >> is the
> >> dev_hard_start_xmit() called for macvtap does not have any
> >> synchronization.
> >>
> >> Fix this by forbidding L2 forwarding for macvtap.
> >>
> >> Cc: John Fas
ev_hard_start_xmit().
>
> In the future, it was also required for macvtap l2 forwarding support since it
> provides a necessary synchronization method.
>
> Cc: John Fastabend
> Cc: Neil Horman
> Cc: e1000-de...@lists.sourceforge.net
> Signed-off-by: Jason Wang
Inste
On Mon, Jan 06, 2014 at 07:06:25AM -0800, John Fastabend wrote:
> On 01/06/2014 04:42 AM, Neil Horman wrote:
> >On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote:
> >>Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit().
> >>The
&g
└── 40
>
> As there was only one file "mode" with the kobject model, the interrupt
> number is now a file that returns the "mode" of the interrupt (msi vs.
> msix).
>
> Signed-off-by: Greg Kroah-Hartman
>
Acked-by: Neil Horman
Thanks Greg.
Neil
--
To
On Sun, Dec 22, 2013 at 05:56:59PM -0500, David Miller wrote:
> From: Neil Horman
> Date: Tue, 17 Dec 2013 11:19:57 -0500
>
> > The SCTP protocol has several deprecation warnings in its setsockopt path
> > that
> > can be triggered by unprivlidged users. Sinc
f the kernel, lets make a
common pr_warn_deprecated macro to produce somewhat generalized ratelimited
deprecation warnings easily
Signed-off-by: Neil Horman
CC: Vlad Yasevich
CC: David Miller
CC: Greg Kroah-Hartman
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
Change note
sctp has several points in its setsockopt path in which it issues deprecation
warnings. It seems like it might be handy to macrotize such a warning so other
subsystems can use it easily
Signed-off-by: Neil Horman
CC: Greg Kroah-Hartman
CC: "David S. Miller"
CC: linux-kernel@vger.ker
On Mon, Dec 23, 2013 at 10:55:16PM +, Ben Hutchings wrote:
> On Mon, 2013-12-23 at 08:29 -0500, Neil Horman wrote:
> > The SCTP protocol has several deprecation warnings in its setsockopt path
> > that
> > can be triggered by unprivlidged users. Since these are not rat
> >>> it when the problem clears.
> >>>
> >>> We can do this with kthread_park and unpark but they are not exported
> >>> from the kernel, this patch exports the needed functions.
> >>>
> >>> Signed-off-by: David Kershner
We can do this with kthread_park and unpark but they are not exported
> from the kernel, this patch exports the needed functions.
>
> Signed-off-by: David Kershner
Given that these functions are visible in the header and part of the
kthread_api, I think it makes good sense to do thi
On Mon, Jul 27, 2015 at 05:45:50PM +0200, Ingo Molnar wrote:
>
> * David Kershner wrote:
>
> > The s-Par visornic driver, currently in staging, processes a queue
> > being serviced by the an s-Par service partition. We can get a message
> > that something has happened with the Service Partition,
txen_process_cmd_ring(struct netxen_adapter
> *adapter)
>*/
> hw_consumer = le32_to_cpu(*(tx_ring->hw_consumer));
> done = (sw_consumer == hw_consumer);
> - spin_unlock(&adapter->tx_clean_lock);
> + spin_unlock_bh(&adapter->tx_clean_lock);
the X9.31 bits:
Acked-by: Neil Horman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ff-by: Nicholas Mc Guire
Acked-by: Neil Horman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
_pending != NULL)
> - kfree(asoc->asconf_addr_del_pending);
> + kfree(asoc->asconf_addr_del_pending);
>
> /* AUTH - Free the endpoint shared keys */
> sctp_auth_destroy_keys(&asoc->endpoint_shared_keys);
> --
> 2.2.2
>
>
Sure, seems
On Tue, Feb 17, 2015 at 12:05:23AM +0100, Mikko Rapeli wrote:
> Fixes compilation error:
>
> linux/sctp.h:652:2: error: unknown type name ‘uint32_t’
>
> Signed-off-by: Mikko Rapeli
Acked-by: Neil Horman
> ---
> include/uapi/linux/sctp.h | 4
> 1 file changed, 4
On Mon, Apr 04, 2016 at 09:40:13PM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhor...@redhat.com]
> > Sent: Monday, April 04, 2016 10:35 AM
> > To: Sell, Timothy C
> > Cc: Iban Rodriguez; Kershner, David A; Greg Kroah-H
On Tue, Apr 05, 2016 at 03:49:57PM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhor...@redhat.com]
> > Sent: Tuesday, April 05, 2016 10:58 AM
> > To: Sell, Timothy C
> > Cc: Iban Rodriguez; Kershner, David A; Greg Kroah-H
np_err(np, "%s is a slave device, aborting\n", np->dev_name);
> @@ -770,7 +770,6 @@ int netpoll_setup(struct netpoll *np)
> return 0;
>
> put:
> - np->dev = NULL;
> dev_put(ndev);
> unlock:
> rtnl_unlock();
>
Acked-by: Neil Horman
On Sat, Apr 02, 2016 at 11:20:14PM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Iban Rodriguez [mailto:iban.rodrig...@ono.com]
> > Sent: Saturday, April 02, 2016 1:47 PM
> > To: Kershner, David A; Greg Kroah-Hartman; Benjamin Romer; Sell, Timothy
&
;
> This patch changes the type to u32, which better fits the use.
>
> Signed-off-by: Arnd Bergmann
> Cc: Vlad Yasevich
> Cc: Neil Horman
> Cc: linux-s...@vger.kernel.org
> ---
> net/sctp/sm_make_chunk.c | 2 +-
> net/sctp/sm_statefuns.c | 2 +-
> 2 files changed, 2 in
401 - 500 of 615 matches
Mail list logo
