From: Julian Anastasov
[ Upstream commit 9802d21e7a0b0d2167ef745edc1f4ea7a0fc6ea3 ]
The tot_stats estimator is started only when CONFIG_SYSCTL
is defined. But it is stopped without checking CONFIG_SYSCTL.
Fix the crash by moving ip_vs_stop_estimator into
ip_vs_control_net_cleanup_sysctl.
The ch
From: Florian Westphal
[ Upstream commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f ]
Quoting Samu Kallio:
Basically what's happening is, during netns cleanup,
nf_nat_net_exit gets called before ipv4_net_exit. As I understand
it, nf_nat_net_exit is supposed to kill any conntrack entries which
From: Florian Westphal
[ Upstream commit cd5f336f1780cb20e83146cde64d3d5779e175e6 ]
'last' keeps track of the ct that had its refcnt bumped during previous
dump cycle. Thus it must not be overwritten until end-of-function.
Another (unrelated, theoretical) issue: Don't attempt to bump refcnt of
[ Upstream commit 3d9b142131ef0cde259dbac5cce36f570fcb4902 ]
Otherwise, the reference to external objects (eg. modules) are not
released when the rules are removed.
Cc: # 3.15.x
Cc: # 3.14.x
Signed-off-by: Pablo Neira Ayuso
---
net/netfilter/nft_compat.c | 18 ++
1 file chan
[ Upstream commit 5bc5c307653cbf8fe9da6cbd8ae6c6bd5b86ff4b ]
The patch 5e94846 ("netfilter: nf_tables: add insert operation") did
not include RCU-safe list insertion when replacing rules.
Cc: # 3.15.x
Cc: # 3.14.x
Signed-off-by: Pablo Neira Ayuso
---
net/netfilter/nf_tables_api.c |2 +-
1
[ Upstream commit 266155b2de8fb721ae353688529b2f8bcdde2f90 ]
The dumping prematurely stops, it seems the callback argument that
indicates that all entries have been dumped is set after iterating
on the first cpu list. The dumping also may stop before the entire
per-cpu list content is also dumped.
Dear User,
Due to the high number of different E-mail Accounts that has been Violating our
E-mail policy, terms and conditions.
We recently have determined that different computers have logged into your
account,
and multiple password failures were present before the login. Therefore your
accoun
On Wed, Jul 16, 2014 at 10:02:58AM +0530, Vineet Gupta wrote:
> Hi,
>
> Can you please add the mainline commit
> a4b6cb735b25aa84a462a1985e3e43bebaf5beb4
> "ARC: Implement ptrace(PTRACE_GET_THREAD_AREA)" to stable kernels
>
> This is causing buildroot gdb failures with pre 3.16 kernels.
>
> Thx
Dear User,
Due to the high number of different E-mail Accounts that has been Violating our
E-mail policy, terms and conditions.
We recently have determined that different computers have logged into your
account,
and multiple password failures were present before the login. Therefore your
accoun
At Tue, 15 Jul 2014 21:28:16 -0700,
Guenter Roeck wrote:
>
> On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.15.6 release.
> > There are 84 patches in this series, all will be posted as a response
> > to this one. If anyone has any issu
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > "KY" == KY Srinivasan writes:
>
> KY> Windows hosts do support UNMAP and set the field in the
> KY> EVPD. However, since the host advertises SPC-2 compliance, Linux
> KY> does not even query the VPD page.
>
> >> If we w
As reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1025690
This is yet another model which needs this quirk.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/acpi/video.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi
On Wed, 2014-07-16 at 04:01 -0700, h...@infradead.org wrote:
> On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > > "KY" == KY Srinivasan writes:
> >
> > KY> Windows hosts do support UNMAP and set the field in the
> > KY> EVPD. However, since the host advertises SPC-2 com
> "hch" == hch@infradead org writes:
hch> read_capacity_16 calls sd_config_discard(sdkp, SD_LBP_WS16) if the
hch> LPBME bit is set. At least older SBC drafts left it wide open if a
hch> target supports WRITE SAME with UNMAP or UNMAP in this case.
Correct.
hch> So I think we'd still want a
N�r��yb�X��ǧv�^�){.n�+��z)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
On 07/15/14 20:10, Saravana Kannan wrote:
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 65eed38..349e28ea 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -483,9 +483,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
>
On Wed, Jul 16, 2014 at 05:26:48PM +, KY Srinivasan wrote:
> Christoph,
>
> Is this patch-set ready to be checked in. Let me know if you want me to make
> any
> further corrections.
Hi Ky,
I've applied it locally, but I'm still waiting on reviews for two
important core fixes before pushing
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Monday, July 14, 2014 1:58 AM
> To: Christoph Hellwig
> Cc: KY Srinivasan; jasow...@redhat.com; a...@canonical.com; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@para
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Wednesday, July 16, 2014 10:29 AM
> To: KY Srinivasan
> Cc: Hannes Reinecke; jasow...@redhat.com; a...@canonical.com; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbott
On Wed, Jul 16, 2014 at 11:44:18AM -0400, Martin K. Petersen wrote:
> There are lots of devices out there that support WRITE SAME(10) or (16)
> without the UNMAP bit. And there are devices that support WRITE SAME w/
> UNMAP functionality but not "regular" WRITE SAME.
Oh, we actually have devices t
> "Christoph" == hch@infradead org writes:
Christoph> Oh, we actually have devices that support WRITE SAME with
Christoph> unmap, but not without? That's defintively a little strange.
Yep :(
There were several SSDs that did not want to support wearing out flash
by writing gobs of zeroes an
On Wed, Jul 16, 2014 at 01:47:35PM -0400, Martin K. Petersen wrote:
> There were several SSDs that did not want to support wearing out flash
> by writing gobs of zeroes and only support the UNMAP case.
Given that SSDs usually aren't hard provisioned anyway that seems like
an odd decision. But SAS
On Wed, 2014-07-16 at 13:47 -0400, Martin K. Petersen wrote:
> > "Christoph" == hch@infradead org writes:
>
> Christoph> Oh, we actually have devices that support WRITE SAME with
> Christoph> unmap, but not without? That's defintively a little strange.
>
> Yep :(
>
> There were several SSD
This reverts commit 3adee7a7976012a20f1d3b5a529a3c105e29fef1.
After upgrading to v3.15, my laptop's battery started draining quite
fast. Powertop pointed to the deep RC6 states not being used. The
kernel param I had put to enable them had stopped working the way it
used to; so I disagree with th
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of James Bottomley
> Sent: Wednesday, 16 July, 2014 1:02 PM
> To: martin.peter...@oracle.com
> Cc: linux-ker...@vger.kernel.org; h...@infradead.org;
> de...@linuxdriverproj
> "James" == James Bottomley writes:
>> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
>> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
>> does fix the problem at hand. That's why I went that route.
James> Hang on ... unless we apply Christoph or m
On Wed, 2014-07-16 at 14:45 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> >> I don't have a problem with a BLIST_PREFER_UNMAP flag or something
> >> like that. But BLIST_TRY_VPD_PAGES seems more generally useful and it
> >> does fix the problem at hand. That's wh
> "James" == James Bottomley writes:
James> It's the code we identified in sd.c:read_capacity_16():
That's there to support devices that implement thin provisioning but
which predate the LBP VPD page. And thus have no way to tell us their
preferred command variant.
James> If the inquiry sho
On Wed, 2014-07-16 at 15:08 -0400, Martin K. Petersen wrote:
> > "James" == James Bottomley writes:
>
> James> It's the code we identified in sd.c:read_capacity_16():
>
> That's there to support devices that implement thin provisioning but
> which predate the LBP VPD page. And thus have no w
> "Rob" == Elliott, Robert (Server Storage) writes:
Rob> WRITE SAME with the UNMAP bit set to one (and a few other
Rob> conditions) guarantees that the data is zeroed out, while the UNMAP
Rob> command is just a hint. They're not fully interchangeable. Which
Rob> semantics are implied by REQ
> "James" == James Bottomley writes:
James> Well, your judgement: is this situation (support for UNMAP but
James> not for WRITE_SAME) in what is effectively a RAID driver (hv
James> drivers count as RAID) just a silly Microsoft one off?
I only recall seeing one or two devices that supported
On Wednesday, July 16, 2014 01:28:34 PM Hans de Goede wrote:
> As reported here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1025690
> This is yet another model which needs this quirk.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede
Applied, thanks!
But I'm not going to tag it f
On Thursday, July 10, 2014 06:11:44 PM Viresh Kumar wrote:
> This is only relevant to implementations with multiple clusters, where
> clusters
> have separate clock lines but all CPUs within a cluster share it.
>
> Consider a dual cluster platform with 2 cores per cluster. During suspend we
> sta
On Tue, Jul 15, 2014 at 04:16:58PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.49 release.
> There are 44 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Tue, Jul 15, 2014 at 04:16:54PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.13 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.15.6 release.
> There are 84 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
On Tue, Jul 15, 2014 at 04:17:05PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.99 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Add code to poll the channel since we process only one message at a time and
the host may not interrupt us. Also increase the receive buffer size since
some KVP messages are close to 8K bytes in size.
This patch failed to apply to the 3.15-stable tree. Here is the original
commit information:
>Fr
On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote:
On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.15.6 release.
There are 84 patches in this series, all will be posted as a response
to this one. If anyone has any issues
On 17 July 2014 04:48, Rafael J. Wysocki wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> +static int update_policy_cpu(struct cpufreq_policy *policy, unsigned int
>> cpu,
>> + struct device *cpu_dev)
>> {
>> + int ret;
>> +
>> if
Setting vm_dirty_bytes and dirty_background_bytes is not protected by any
serialization.
Therefore, it's possible for either variable to change value after the
test in global_dirty_limits() to determine whether available_memory needs
to be initialized or not.
Always ensure that available_memor
Quite frankly, to me this patch just does too much in one go without
describing about a half of things it is doing.
I would just add the kobject_move() call to __cpufreq_add_dev() to
start with (because that's what you really want if I'm not mistaken)
and do the cleanups separately, later.
On Thu
On Wed, Jul 16, 2014 at 05:12:28PM -0700, Guenter Roeck wrote:
> On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote:
> >On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote:
> >>This is the start of the stable review cycle for the 3.15.6 release.
> >>There are 84 patches in this series,
On Wed, Jul 16, 2014 at 07:53:41PM +0900, Satoru Takeuchi wrote:
> At Tue, 15 Jul 2014 21:28:16 -0700,
> Guenter Roeck wrote:
> >
> > On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.15.6 release.
> > > There are 84 patches in this seri
On Wed, Jul 16, 2014 at 05:36:49PM -0700, David Rientjes wrote:
> Setting vm_dirty_bytes and dirty_background_bytes is not protected by any
> serialization.
>
> Therefore, it's possible for either variable to change value after the
> test in global_dirty_limits() to determine whether available_m
On 17 July 2014 06:19, Rafael J. Wysocki wrote:
> Quite frankly, to me this patch just does too much in one go without
> describing about a half of things it is doing.
>
> I would just add the kobject_move() call to __cpufreq_add_dev() to
> start with (because that's what you really want if I'm no
This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.
Consider a dual cluster platform with 2 cores per cluster. During suspend we
start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->ko
47 matches
Mail list logo
