On Fri, 2013-09-13 at 05:47 -0400, Jun Chen wrote:
> On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> > On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > > When try to add node to list in __inet_hash_nolisten function, first get
> > > the
> > > list and then to lock for using, but in
When numa for perf bench is compiled will have core dump.
| #./perf bench numa all
| # Running numa/mem benchmark...
|
| Segmentation fault (core dumped)
| # ./perf bench all
| # Running numa/mem benchmark...
|
| Segmentation fault (core dumped)
Fix it by adding own handler for numa bench.
Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
Hi Jörn,
>On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
>> Though
>> I probably should be hesitant with my suggestions, as I'm not well
>> versed in RNG theory.
>
>The basic principle of Ted's RNG is very simple and
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
So I'm poking around the preemption code and
Hi Linus,
please pull blackfin updates for Linux 3.12, some minor bug fixes.
The following changes since commit 6e4664525b1db28f8c4e1130957f70a94c19213e:
Linux 3.11 (2013-09-02 13:46:10 -0700)
are available in the git repository at:
* David Ahern wrote:
> > By default a simple 'make' should build perf to the maximum extent
> > possible, with no other input required from the user - with warnings
> > displayed as package install suggestions.
>
> By default there is no config. Autoprobing generates a first one or a
> user
Le 12/09/2013 20:44, Scott Wood a écrit :
On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
This is a reorganisation of the setup of the TLB at kernel startup, in order
to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866
and MPC885 reference manuals.
Odd, the 00/23 mail for 3.4.62 doesn't show up on lkml.
So this mail will most likely show up as reply to 01/23.
Anyway, here are my build results for 3.4.62:
total: 103 pass: 89 skipped: 10 fail: 4
More configurations (added two crisv32 as well as several arm builds),
one less failure
From: Michael Opdenacker [mailto:michael.opdenac...@free-electrons.com]
Data: Friday, September 13, 2013 11:45 AM
> To: da...@davemloft.net; Estevam Fabio-R49496
> Cc: frank...@freescale.net; Duan Fugang-B38611; jim_bax...@mentor.com;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org;
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/toshiba/ps3_gelic_net.c
It's a NOOP since 2.6.35 and I will remove it one day ;)
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
1 file changed, 1 insertion(+), 1
This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/smsc/
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/smsc/smc91x.h | 2 +-
drivers/net/ethernet/smsc/smsc9420.c | 3 +--
2 files
On 12 September 2013 22:56, Srivatsa S. Bhat
wrote:
> On 09/12/2013 09:25 PM, Stephen Warren wrote:
> Anyway, nevermind, as of now, subsystems do work around this suitably, so
> there is no known bug as such at the present. Just that we could have probably
> done it a better way, that's all.
On 12 September 2013 15:40, Viresh Kumar wrote:
> Some part of this patch was pushed in mainline earlier but was then removed
> due
> to loopholes in the patch. Those are now fixed and this patch is tested by the
> people who reported these problems.
>
> Whenever we are changing frequency of a
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/pasemi/pasemi_mac.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/pasemi/pasemi_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/natsemi/
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/natsemi/jazzsonic.c | 3 +--
drivers/net/ethernet/natsemi/xtsonic.c | 3 +--
2
Hi all,
Please do not add any code for v3.13 to your linux-next included branches
until after v3.12-rc1 is released.
Changes since 20130912:
The akpm tree lost lots of patches that turned up in Linus' tree.
I have
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/micrel/ks8851_mll.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/marvell/pxa168_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c
b/drivers/net/ethernet/marvell/pxa168_eth.c
index 4ae0c74..fff6246 100644
---
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/lantiq_etop.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/lantiq_etop.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
On Thu, 12 September 2013 22:13:49 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 06:23:09PM -0400, Jörn Engel wrote:
> > It is worse in three ways:
> > - it costs performance,
> > - it may create a false sense of safety and
> > - it actively does harm if we credit it as entropy.
> >
> >
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/hp/hp100.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/hp/hp100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This message is from Naukri.com to all Employers registered With Naukri.com. we
are currently carrying out maintainance exercise to improve our quality
service and reduce the rate of spam in our job portal.
Please confirm and upgrade your employers account click the link blow
This message is from Naukri.com to all Employers registered With Naukri.com. we
are currently carrying out maintainance exercise to improve our quality
service and reduce the rate of spam in our job portal.
Please confirm and upgrade your employers account click the link blow
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/freescale/fec_main.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Sep 13, 2013 at 11:38:04AM +0800, Fengguang Wu wrote:
> On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> > On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> > > Hi Peter,
> > >
> > > FYI, we noticed much increased vmap_area_lock contentions since this
> > > commit:
On Thu, Sep 12, 2013 at 08:17:00PM -0700, Greg KH wrote:
> On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> > Hi Peter,
> >
> > FYI, we noticed much increased vmap_area_lock contentions since this
> > commit:
>
> What does that mean? What is happening, are we allocating/removing
Hi Toshi,
On 09/13/2013 03:22 AM, Toshi Kani wrote:
..
+ if (memblock_direction_bottom_up()) {
+ addr = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+
From: Michael Opdenacker
Date: Thu, 12 Sep 2013 05:35:43 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/adi/bfin_mac.c.
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Applied.
--
To unsubscribe from
From: Michael Opdenacker
Date: Thu, 12 Sep 2013 06:20:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/dec/tulip/de4x5.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Applied.
--
To unsubscribe
From: Michael Opdenacker
Date: Thu, 12 Sep 2013 05:52:50 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/amd/sun3lance.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Applied.
--
To unsubscribe from
From: Michael Opdenacker
Date: Thu, 12 Sep 2013 05:46:11 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/ibm/ehea/ehea_main.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Applied.
--
To unsubscribe
On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote:
> Hi Peter,
>
> FYI, we noticed much increased vmap_area_lock contentions since this
> commit:
What does that mean? What is happening, are we allocating/removing more
memory now?
What type of load were you running that showed this
Hi Dave/Thomas
On 2013年09月13日 01:32, David Miller wrote:
From: Thomas Gleixner
Date: Thu, 12 Sep 2013 16:43:37 +0200 (CEST)
So what about going back to timer_list timers and simply utilize
register_pm_notifier(), which will tell you that the system resumed?
The thing to understand is that
On Thu, 12 Sep 2013 22:29:44 -0400
Boris Ostrovsky wrote:
> From: Konrad Rzeszutek Wilk
>
> xen_init_spinlocks() currently calls static_key_slow_inc() before
> jump_label_init() is invoked. When CONFIG_JUMP_LABEL is set (which usually is
> the case) the effect of this static_key_slow_inc() is
From: Konrad Rzeszutek Wilk
xen_init_spinlocks() currently calls static_key_slow_inc() before
jump_label_init() is invoked. When CONFIG_JUMP_LABEL is set (which usually is
the case) the effect of this static_key_slow_inc() is deferred until after
jump_label_init(). This is different from when
On Thu, Sep 12, 2013 at 06:23:09PM -0400, Jörn Engel wrote:
> It is worse in three ways:
> - it costs performance,
> - it may create a false sense of safety and
> - it actively does harm if we credit it as entropy.
>
> How much weight you assign to each of those is up to you. So long as
> we
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL. It also removes unnecessary label such
as 'err_request'.
Signed-off-by: Jingoo Han
---
Changes since v1:
- Removed unnecessary label
On Thu, Sep 12, 2013 at 9:30 PM, Rusty Russell wrote:
> Peter Chen writes:
>> Currently, if module's refcount is not zero during the unload,
>> it waits there until the user decreases that refcount.
>
> Hi Peter,
>
> In practice userspace uses O_NONBLOCK. In fact, I've been
> thinking
On Sep 12, 2013, at 5:47 PM, David Brown wrote:
> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote:
>>
>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>
>>> My original request to please use a common prefix for your product
>>> families stands. Please prefix with msm-*, or if
Add the virt-server mode for a virtualization environment based on the listen
mode for networking. This mode works like client/server mode over TCP/UDP,
but it uses virtio-serial channel instead of IP network. Using networking for
collecting trace data of guests is generally high overhead caused
Use poll(2) to wait for a message. If a client/server cannot send a message for
any reasons, the current server/client will wait in a blocking read operation.
So, we use poll(2) for avoiding remaining in a blocking state.
Signed-off-by: Yoshihiro YUNOMAE
---
trace-msg.c | 42
Apply trace-msg protocol for communication between a server and clients.
Currently, trace-listen(server) and trace-record -N(client) operate as follows:
listen to socket fd
connect to socket fd
accept the client
send
Add --virt option for record mode for a virtualization environment.
If we use this option on a guest, we can send trace data in low-overhead.
This is because guests can send trace data to a host without copying the data
by using splice(2).
The format is:
trace-cmd record --virt -e sched*
Hi Steven,
This is a v2 patch set for realizing a part of "Integrated trace" feature which
is a trace merging system for a virtualization environment. Currently, trace-cmd
does not have following features yet:
a) Server and client for a virtualization environment
b) Structured message platform
Split out binding a port and fork reader from open_udp() for avoiding duplicate
codes between listen mode and virt-server mode.
Changes in V2: Add a comment in open_udp()
Signed-off-by: Yoshihiro YUNOMAE
---
trace-listen.c | 38 ++
1 file changed, 30
On Fri, Sep 13, 2013 at 10:00:33AM +0930, Rusty Russell wrote:
> Peter Chen writes:
> > Currently, if module's refcount is not zero during the unload,
> > it waits there until the user decreases that refcount.
>
> Hi Peter,
>
> In practice userspace uses O_NONBLOCK. In fact, I've been
Firstly, I am glad to see that you did not redirect all my mails to
"/dev/null". ;-)
On 09/13/2013 07:36 AM, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Darren Hart wrote:
>> On Thu, 2013-09-12 at 16:32 +0200, Thomas Gleixner wrote:
>>> On Tue, 20 Aug 2013, Chen Gang wrote:
>>>
On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > When try to add node to list in __inet_hash_nolisten function, first get the
> > list and then to lock for using, but in extremeness case, others can del
> > this
> > node before
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Thursday, September 12, 2013 5:28 PM
> To: KY Srinivasan
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
>
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
>> On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote:
>>> Now the real question is, how that expansion mechanism is supposed to
>>> work. There are two possible scenarios:
>>>
On 09/12/2013 08:45 PM, Hillf Danton wrote:
> If a page monitored by ANB is migrated, its footprint should be erased from
> numa-hint-fault account, because it is no longer used. Or two pages, the
> migrated page and its target page, are used in the view of task placement.
>
>
> Signed-off-by:
On 09/12/2013 10:34 AM, Paul E. McKenney wrote:
> On Wed, Sep 11, 2013 at 11:39:31PM -0400, Miles Lane wrote:
>> [ 29.804534] [ INFO: suspicious RCU usage. ]
>> [ 29.804539] 3.11.0+ #5 Not tainted
>> [ 29.804541] ---
>> [ 29.804545]
On Thu, Sep 12, 2013 at 06:12:24PM -0700, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
> wrote:
> >
> > I'll walk through the code, it looked suspicious. Maybe there's
> > something subtle that makes it work, but I don't see it.
>
> Btw, it's not just the
On Thu, 12 September 2013 19:35:36 -0400, Jörn Engel wrote:
>
> I think the existing code is doing just fine for low interrupt loads.
> It makes sense to spend a bit more work to squeeze the last bit of
> randomness out. But when you get lots of interrupts, you can be
> sloppy and just xor
On 09/13/2013 06:37 AM, Darren Hart wrote:
> On Thu, 2013-09-12 at 16:32 +0200, Thomas Gleixner wrote:
>> On Tue, 20 Aug 2013, Chen Gang wrote:
>>
>>> rt_mutex_finish_proxy_lock() can return failure code (e.g. -EINTR,
>>> -ETIMEDOUT).
>>>
>>> Original implementation has already noticed about it,
Dear Manangers,
Have a nice day!
We are Qingdao HeBangRui Fine Chemicals Co., Ltd, the professional manufacture
and exporter of titanium dioxide ( Rutiel & Anatase) in China for many years .
Titanium dioxide,
chemical formula TiO2, commonly known as titanium dioxide, used photocatalyst,
Hi Olof,
El 12/09/13 21:57, Olof Johansson escribió:
On Thu, Sep 12, 2013 at 5:30 PM, Emilio López wrote:
This driver's only job is to claim and ensure the necessary clock
for memory operation on a DT-powered machine remains enabled.
Signed-off-by: Emilio López
---
I believe this new patch
On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
wrote:
>
> I'll walk through the code, it looked suspicious. Maybe there's
> something subtle that makes it work, but I don't see it.
Btw, it's not just the DCACHE_LRU_LIST bit. The games with
"nr_dentry_unused" look totally broken too. It's
On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
> On 09/11/2013 05:32 PM, Mika Westerberg wrote:
>> From: Aaron Lu
>>
>> This patch adds runtime PM support for the I2C bus in a similar way that
>> has been done for PCI bus already. This means that the I2C bus core
>> prepares runtime PM for a
On Thu, 12 September 2013 19:31:55 -0400, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
> >
> > I happen to have a real-world system with >100k interrupts per second
> > and - surprise - add_interrupt_randomness() showed up prominently in
> > the profiles. I
hmm, looks like I cargo-cult'd the same into msm.
I guess in i915 (and ttm) case, the issue arises due to need for CPU
access to buffer via GTT? In which case I should be safe to drop the
set_need_resched() as well? (Since CPU always has direct access to the
pages.) Or am I missing something
On Thu, Sep 12, 2013 at 5:30 PM, Emilio López wrote:
> This driver's only job is to claim and ensure the necessary clock
> for memory operation on a DT-powered machine remains enabled.
>
> Signed-off-by: Emilio López
> ---
>
> I believe this new patch should resolve all the concerns raised; as
>
Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
The devices generate low-jitter clock signals and are reprogrammable via
an I2C interface.
Cc: Guenter Roeck
Signed-off-by: Soren Brinkmann
---
.../devicetree/bindings/clock/silabs,si570.txt | 31 ++
drivers/clk/Kconfig
On Tue, Sep 10, 2013 at 4:37 PM, Linus Torvalds
wrote:
>
> From a quick look, this looks pretty broken:
>
> if (list_lru_add(>d_sb->s_dentry_lru, >d_lru))
> this_cpu_inc(nr_dentry_unused);
> dentry->d_flags |= DCACHE_LRU_LIST;
>
> because if that list_lru_add() can fail, then we
This is another try to submit a driver for SI570 programmable clock
generators. The heart of the driver is Günther's code from
https://github.com/groeck/si570, which is wrapped in the common
clock infrastructure.
Due to the lack of platforms with oder devices only the SI570 is
actually tested.
Hi Peter,
FYI, we noticed much increased vmap_area_lock contentions since this
commit:
commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77
Author: Peter Hurley
Date: Sat Jun 15 10:21:19 2013 -0400
n_tty: Move buffers into n_tty_data
Reduce pointer reloading and improve
Peter Chen writes:
> Currently, if module's refcount is not zero during the unload,
> it waits there until the user decreases that refcount.
Hi Peter,
In practice userspace uses O_NONBLOCK. In fact, I've been
thinking of removing the blocking case altogether, since it's not really
what
Lucas De Marchi writes:
> On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
> wrote:
>> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>>> Herbert Xu writes:
>>> > Hi Rusty:
>>> >
>>> > I don't know why this patch never went into the kernel, even
>>> > though the corresponding
Since the MAX_VICTIM_SEARCH has been enlarged from 20 to 4096,
the victim searching overhead will be increased much than before,
especially for SSR that searches victim for use quiet often.
This patch intends to reduce the overhead a little bit by:
- make the get_gc_cost a inline routine to reduce
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions in
_CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
> On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote:
> > Now the real question is, how that expansion mechanism is supposed to
> > work. There are two possible scenarios:
> >
> > 1) Expand the number of handled interrupts beyond the GIC
This is a patch to the fsfilt.c file that fixes up three assignment in if
condition errors found by the checkpatch.pl tool.
Signed-off-by: Jon Bernard
---
drivers/staging/lustre/lustre/lvfs/fsfilt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
On 09/12/2013 04:07 PM, Greg Kroah-Hartman wrote:
On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.11.1 release.
There are 16 patches in this series, all will be posted as a
On 09/12/2013 05:06 PM, KY Srinivasan wrote:
>
> Peter,
>
> Let me know if you want me to address any additional issues in this patch.
>
Please address Jan and Gleb's feedback.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Fri, Sep 13, 2013 at 12:47 AM, Greg Kroah-Hartman
wrote:
> On Wed, Sep 04, 2013 at 02:47:07PM +0200, Tom Gundersen wrote:
>> Most of the information in usb.ids is now contained in udev's hwdb. Read the
>> information from the hwdb instead of usb.ids.
>>
>> This would allow distributions to no
On 08/29/2013 02:01 AM, Matt Wilson wrote:
> On Fri, Mar 22, 2013 at 09:32:54AM -0400, Prarit Bhargava wrote:
>> The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
>> registers to userspace. The Kconfig help points out that in some cases this
>> can be a security risk as
This driver's only job is to claim and ensure the necessary clock
for memory operation on a DT-powered machine remains enabled.
Signed-off-by: Emilio López
---
I believe this new patch should resolve all the concerns raised; as
always, all feedback is welcome :)
Changes from RFC:
- Move from
So this is just a heads-up that while I haven't actually closed the
merge window yet, I was really close to deciding to just make this one
a short one. I'm going to be on the road for the next few days and
then at LinuxCon US later next week, and I've tried very hard to merge
everything I had
This is a patch to the fsfilt.c file that fixes up a brace warning found by the
checkpatch.pl tool.
Signed-off-by: Jon Bernard
---
drivers/staging/lustre/lustre/lvfs/fsfilt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lvfs/fsfilt.c
On Wed, Sep 11, 2013 at 08:46:04AM +0200, Tibor Billes wrote:
> > From: Paul E. McKenney Sent: 09/09/13 10:44 PM
> > On Mon, Sep 09, 2013 at 09:47:37PM +0200, Tibor Billes wrote:
> > > > From: Paul E. McKenney Sent: 09/08/13 08:43 PM
> > > > On Sun, Sep 08, 2013 at 07:22:45PM +0200, Tibor Billes
> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Tuesday, September 03, 2013 11:30 AM
> To: x...@kernel.org; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
>
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Thursday, September 12, 2013 3:27 PM
> To: Skidmore, Donald C
> Cc: e1000-de...@lists.sourceforge.net; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Don Dutile
> Subject: Re: [E1000-devel]
On Thu, 12 September 2013 16:51:15 -0700, Andy Lutomirski wrote:
>
> Supposedly, the Linux entropy pool has the property that mixing in
> even actively malicious data is no worse than not mixing in anything
> at all.
It is worse in three ways:
- it costs performance,
- it may create a false
On Thu, Sep 12, 2013 at 3:13 PM, Jörn Engel wrote:
> On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
>> On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
>> > On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>> >> But I also think that the existing (certified) TPMs
Hi Thomas,
On Thu, Sep 12, 2013 at 10:30:15PM +0200, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Soren Brinkmann wrote:
> > From: Stephen Boyd
> >
> > On most ARM systems the per-cpu clockevents are truly per-cpu in
> > the sense that they can't be controlled on any other CPU besides
> > the
On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
> On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
> > On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
> >> But I also think that the existing (certified) TPMs are good enough
> >> for direct use.
>
> > That is
On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel wrote:
> On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>> But I also think that the existing (certified) TPMs are good enough
>> for direct use.
> That is equivalent to trusting the TPM chip not to be malicious. It
Indeed. While it
On Thu, Sep 12, 2013 at 2:57 PM, Jörn Engel wrote:
> On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>>
>> But I also think that the existing (certified) TPMs are good enough
>> for direct use.
>
> That is equivalent to trusting the TPM chip not to be malicious. It
> requires
On Thu, 12 Sep 2013, Darren Hart wrote:
> On Thu, 2013-09-12 at 16:32 +0200, Thomas Gleixner wrote:
> > On Tue, 20 Aug 2013, Chen Gang wrote:
> >
> > > rt_mutex_finish_proxy_lock() can return failure code (e.g. -EINTR,
> > > -ETIMEDOUT).
> > >
> > > Original implementation has already noticed
On Thu, Sep 12, 2013 at 05:07:17PM -0400, Jörn Engel wrote:
>
> I happen to have a real-world system with >100k interrupts per second
> and - surprise - add_interrupt_randomness() showed up prominently in
> the profiles. I was also told twice to just remove that call. I
> resisted both times
On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
>
> But I also think that the existing (certified) TPMs are good enough
> for direct use.
That is equivalent to trusting the TPM chip not to be malicious. It
requires trusting the chip designer, trusting every single employee of
the
Dear Purchasing manager:
here is paper leading supplier from China
our main products include A3 copy paper, A4 copy paper, offset paper, newsprint
paper and so on
we can do the packing as customer's request
if you need any of them please reply me
Best wishes
Sunny
Manager
North China Lutuo
On Thu, Sep 12, 2013 at 03:29:05PM -0700, Guenter Roeck wrote:
> On 09/12/2013 10:26 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.0.96 release.
> >There are 19 patches in this series, all will be posted as a response
> >to this one. If anyone has any
On Thu, Sep 12, 2013 at 03:35:09PM -0700, Guenter Roeck wrote:
> On 09/12/2013 10:58 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.12 release.
> >There are 46 patches in this series, all will be posted as a response
> >to this one. If anyone has any
On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
> On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.11.1 release.
> >There are 16 patches in this series, all will be posted as a response
> >to this one. If anyone has any
tip-bot for Peter Zijlstra wrote:
> Commit-ID: 863bffc80898b8df295ebac111af2335ec05f85d
> Gitweb: http://git.kernel.org/tip/863bffc80898b8df295ebac111af2335ec05f85d
> Author: Peter Zijlstra
> AuthorDate: Wed, 28 Aug 2013 11:44:39 +0200
> Committer: Ingo Molnar
> CommitDate: Thu, 12
On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
> Though
> I probably should be hesitant with my suggestions, as I'm not well
> versed in RNG theory.
The basic principle of Ted's RNG is very simple and quite sane:
- You collect as much data as possible, some of which is (hopefully)
On Wed, Sep 04, 2013 at 02:47:08PM +0200, Tom Gundersen wrote:
> Also remove usb.ids from the repository. [Note that these were probably
> never used by distributions regarless, as most distros ship the usb.ids
> directly from upstream.]
>
> Hardcode the usb-spec information that used to be in
On Wed, Sep 04, 2013 at 02:47:07PM +0200, Tom Gundersen wrote:
> Most of the information in usb.ids is now contained in udev's hwdb. Read the
> information from the hwdb instead of usb.ids.
>
> This would allow distributions to no longer ship (most of) usb.ids by default,
> but rather keep all
On Thu, 12 September 2013 14:15:35 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller wrote:
> >>BTW, I prefer a different name than "random_get_fast_cycles()", as it's
> >>better to have something that returns different and unpredictable
> >>numbers than an
1 - 100 of 1670 matches
Mail list logo
