I found 2 problems at my platform.
1st is occured when I set CMA size 528MB and total memory is 960MB.
I print some values in adjust_managed_cma_page_count(),
the total value becomes 105439 and cma value 131072.
Finally movable value becomes negative value.
The total value 105439 means 411MB.
We need number of pagecache tags in later patches, this patch prepares it.
Signed-off-by: Naoya Horiguchi
---
include/linux/fs.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git v3.15-rc7.orig/include/linux/fs.h v3.15-rc7/include/linux/fs.h
index
This patch provides a new system call fincore(2), which provides mincore()-
like information, i.e. page residency of a given file. But unlike mincore(),
fincore() can have a mode flag and it enables us to extract more detailed
information about page cache like pfn and page flag. This kind of
This patch adds simple test programs for fincore(), which contains the
following testcase:
- test_unaligned_start_address
- test_unaligned_start_address_hugetlb
- test_invalid_mode
- test_smallfile_bytemap
- test_smallfile_pfn
- test_smallfile_multientry
- test_largefile_pfn
-
Due to the previous discussion[1], I learned that you people have discussed
this system call a few times (but not conclusion) and it can solve my problem
about pagecache scanning (see[2] for my motivation.) So I try it now.
The main patch of this patchset is patch 2, and this is based on
Adds a label for "kfree(brd)". And also remove
a state value as BOARD_FAILED in brd when dgap_do_remap() is failed.
Because "brd" will free after failure.
Signed-off-by: Daeseok Youn
Reviewed-by: Dan Carpenter
---
RESEND: this patch is included into newly series of patches.
V2: add
From: Jon Maxwell
Date: Thu, 29 May 2014 17:27:16 +1000
> There has been a number incidents recently where customers running KVM have
> reported that VM hosts on different Hypervisors are unreachable. Based on
> pcap traces we found that the bridge was broadcasting the ARP request out
> onto the
Hi,
I think you missed a cleanup_srcu_struct(>irq_srcu) in kvm_destroy_vm().
On Mon, May 5, 2014 at 10:26 PM, Paolo Bonzini wrote:
> Il 05/05/2014 16:21, Christian Borntraeger ha scritto:
>
>> On 28/04/14 18:39, Paolo Bonzini wrote:
>>>
>>> From: Christian Borntraeger
>>
>>
>> Given all your
On Sun, 2014-06-01 at 21:56 -0700, David Miller wrote:
> Indeed you have to provide a dummy version for a non-SMP build etc.
>
> I'm reverting.
>
Hi David. I think your revert took one wrong commit.
# git show ee39facbf82e73e468c504d2b40e83e2d223c28c | diffstat -p1 -w70
Hi Chris,
On Mon, 26 May 2014 14:07:35 +1000 Stephen Rothwell
wrote:
>
> After merging the mmc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_notify_change':
> drivers/mmc/host/sdhci-s3c.c:402:25: error:
The dgap_config_buf is only used in dgap_firmware_load().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 3e716fe..c78c8e2 100644
---
- The dgap_tty_register_ports() needs to handle if the
tty_port_register_device() fails.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 44 +-
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c
Dear Greg,
This is extcon-next-v2 full request for v3.16. This pull request includes
additional patchset after merged previous extcon-next pull
request(tags/extcon-next-for-v3.16).
I add detailed description of this pull request on below. Please pull extcon
with following update.
Best Regards,
If the kzalloc() fails for channels, it need to handle
that error. It should free channels which were already
allocated.
And also removes the call to dgap_tty_uninit() in
dgap_firmware_load().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 18 +-
1 files
- The channels array were set to NULL in dgap_found_board().
- Removes redundant null check for channels array in for loop,
if one of the channel cannot be allocated, dgap_tty_init() just returns
an error.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 13 -
1 files
Adds a label for "kfree(brd)". And also remove
a state value as BOARD_FAILED in brd when dgap_do_remap() is failed.
Because "brd" will free after failure.
Signed-off-by: Daeseok Youn
---
RESEND: this patch is included into newly series of patches.
drivers/staging/dgap/dgap.c | 19
The dgap_probe1() function is just calling dgap_found_board().
So it is removed and dgap_found_board() is called directly.
Signed-off-by: Daeseok Youn
---
RESEND : this patch is included into newly serise of patches
so renumbered and resend.
drivers/staging/dgap/dgap.c |8 +---
1 files
From: Eric Dumazet
Date: Sun, 01 Jun 2014 21:37:11 -0700
> On Sun, 2014-06-01 at 21:16 -0700, Eric Dumazet wrote:
>> CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function
>> ‘mlx4_en_init_affinity_hint’:
>>
From: Eric Dumazet
Date: Sun, 01 Jun 2014 21:16:50 -0700
> CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function
> ‘mlx4_en_init_affinity_hint’:
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1546:23: error: incompatible
>
Hello,
On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> > The aspect which really worries me is this: the maintenance burden.
> > This approach would add some peculiar new code, introducing a rare
> > special case:
On Fri, May 30, 2014 at 05:51:11PM +0400, Vladimir Davydov wrote:
> There is no use in keeping free objects/slabs on dead memcg caches,
> because they will never be allocated. So let's make cache_reap() shrink
> as many free objects from such caches as possible.
>
> Note the difference between
On Sun, 2014-06-01 at 21:16 -0700, Eric Dumazet wrote:
> On Sun, 2014-05-25 at 17:47 +0300, Amir Vadai wrote:
> > From: Yuval Atias
> >
> > The “affinity hint” mechanism is used by the user space
> > daemon, irqbalancer, to indicate a preferred CPU mask for irqs.
> > Irqbalancer can use this
While I played with my own feature(ex, something on the way to reclaim),
kernel went to oops easily. I guessed reason would be stack overflow
and wanted to prove it.
I found stack tracer which would be very useful for me but kernel went
oops before my user program gather the information via
On Sat, May 31, 2014 at 03:04:58PM +0400, Vladimir Davydov wrote:
> On Fri, May 30, 2014 at 09:57:10AM -0500, Christoph Lameter wrote:
> > On Fri, 30 May 2014, Vladimir Davydov wrote:
> >
> > > (3) is a bit more difficult, because slabs are added to per-cpu partial
> > > lists lock-less.
I'm not seeing where there is a problem, unless you are trying to assume that
you have no right to distribute them at all.
there is no source for the .config file, it is the source. so when you
distribute it, you are complying with any distribution requirements.
it could be argued that
On Sun, 2014-05-25 at 17:47 +0300, Amir Vadai wrote:
> From: Yuval Atias
>
> The “affinity hint” mechanism is used by the user space
> daemon, irqbalancer, to indicate a preferred CPU mask for irqs.
> Irqbalancer can use this hint to balance the irqs between the
> cpus indicated by the mask.
>
Hi Joonsoo,
CC'ing the developer of the patch (Tomasz Stanislawski)
On Fri, May 30, 2014 at 8:16 PM, Joonsoo Kim wrote:
> 2014-05-30 19:40 GMT+09:00 Ritesh Harjani :
>> Hi Joonsoo,
>>
>> I think you will be loosing the benefit of below patch with your changes.
>> I am no expert here so please
Jens Axboe writes:
> On 2014-05-30 00:10, Rusty Russell wrote:
>> Jens Axboe writes:
>>> If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
>>
>> Really stable? It improves performance, which is nice. But every patch
>> which goes into the kernel fixes a bug, improves clarity,
On Fri, May 30, 2014 at 12:26 PM, Hartley Sweeten
wrote:
> On Thursday, May 29, 2014 9:44 PM, Chase Southwood wrote:
>> Move the function apci1564_interrupt() from hwdrv_apci1564.c to
>> addi_apci_1564.c. On moving, for now just strip out all of the
>> code for interrupts that the driver does
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/net/ethernet/mellanox/mlx4/cmd.c between commit 1a91de28831a
("mellanox: Logging message cleanups") from the net-next tree and
commit 97982f5a91e9 ("IB/mlx4: Preparation for VFs to issue/receive SMI
(QP0)
On Sun, Jun 01, 2014 at 02:42:48PM -0700, Daniel Phillips wrote:
> Instead of re-implementing part of fs/fs-writeback.c, use a proposed
> net ->writeback super operation to drive delta writeback. For each
> inode that is cleaned, call inode_writeback_done(inode). For each
> inode that will be kept
On Sun, Jun 1, 2014 at 5:49 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-exynos/exynos.c between commits dfbdd3d55403 ("ARM: l2c:
> exynos: remove cache size override"), 25a9ef63cd2b ("ARM: l2c: exynos:
> convert to
On Sun, Jun 01, 2014 at 02:41:02PM -0700, Daniel Phillips wrote:
> ---
> From: Daniel Phillips
> Subject: [PATCH] Add a super operation for writeback
>
> Add a "writeback" super operation to be called in the
> form:
>
> progress = sb->s_op->writeback(sb, , );
>
> The filesystem is
I am Mrs. Magaret Crawford. I have decided pick you for a donation. Please,
contact my attorney via email: mark.laws...@rogers.com
___
This email is intended for the designated recipient(s) only, and may be
confidential,
Signed-off-by: James A Shackleford
---
drivers/staging/vt6655/baseband.c | 300 ++---
1 file changed, 150 insertions(+), 150 deletions(-)
diff --git a/drivers/staging/vt6655/baseband.c
b/drivers/staging/vt6655/baseband.c
index 6f95fb6..490ca96 100644
---
From: Stephen Boyd
Date: Wed, 28 May 2014 13:11:12 -0700
> We shouldn't be using regulator_get_optional() here. These
> regulators are always present as part of the physical design and
> there isn't any way to use an internal regulator or change the
> source of the reference voltage via
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, June 02, 2014 4:02 AM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; Guennadi Liakhovetski;
> David Dajun Chen
> Subject: Re: [PATCH V2] regulator: DA9211 : new
I was really hoping that rc7 would be the last rc, but it appears that
reality is once against conspiring against my well-laid plans, and is
forcing me to do an rc8. It's not like there were a lot of changes,
but the last-minute dcache fixes in particular made it not really sane
to just make a
On Fri, 30 May 2014 13:17:14 + "Baldysiak, Pawel"
wrote:
> Commit 8313b8e57f55b15e5b7f7fc5d1630bbf686a9a97 changed
> way of adding device to read-only array. Used routine
> md_reap_sync_thread() which also trigger finish_reshape(),
> can break reshape process, if it was restarted.
Exactly
From: Benoit Taine
Date: Wed, 28 May 2014 17:14:07 +0200
> @@ -1419,8 +1419,7 @@ static int lpc_eth_drv_probe(struct platform_device
> *pdev)
>
> netdev_dbg(ndev, "IO address start :0x%08x\n",
> res->start);
> - netdev_dbg(ndev, "IO address size
Don't use spaces as tabs, and fix other style errors and warnings.
Signed-off-by: Thomas Wood
---
I think that this is correctly indented now, but I didn't touch the double
parentheses on line 322 because I wasn't sure if they were necessary or not.
On Thursday, May 29, 2014 3:31 PM, Sachin Kamat wrote:
>
> PTR_ERR_OR_ZERO simplifies the code.
>
> Signed-off-by: Sachin Kamat
> Cc: Jingoo Han
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/phy/phy-exynos-dp-video.c |5 ++---
> 1 file changed, 2 insertions(+), 3
On Sun, Jun 01, 2014 at 09:36:26PM -0400, Nicolas Pitre wrote:
> On Sun, 1 Jun 2014, Arnd Bergmann wrote:
> > On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote:
> > For actually running kernels beyond 2038, the best idea I've seen so
> > far is to disallow all broken code at compile time. I
This patch fixes the following sparse warnings:
iwctl.c:76:22: warning: symbol 'iwctl_get_wireless_stats' was not declared.
Should it be static?
iwctl.c:118:5: warning: symbol 'iwctl_giwname' was not declared. Should it be
static?
iwctl.c:131:5: warning: symbol 'iwctl_siwscan' was not declared.
The function iwctl_siwscan() is defined in iwctl.c as:
int iwctl_siwscan(struct net_device *dev,
struct iw_request_info *info,
struct iw_point *wrq,
char *extra)
{
...
This patch updates iwctl.h so that the type of the 3rd parameter (*wqr)
Update declaration of iwctl_private_args to match definition in iwctl.c
Signed-off-by: James A Shackleford
---
drivers/staging/vt6655/iwctl.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.h b/drivers/staging/vt6655/iwctl.h
index
From: Amir Vadai
Date: Sun, 25 May 2014 17:47:25 +0300
> This patchset will set affinity hint to influence IRQs to be allocated on the
> same NUMA node as the one where the card resides. As discussed in
> http://www.spinics.net/lists/netdev/msg271497.html
>
> If the number of IRQs allocated is
On Monday, June 02, 2014 5:27 AM, Wolfram Sang wrote:
> On Sat, May 17, 2014 at 07:14:08PM +0200, Rickard Strandqvist wrote:
> > There is otherwise a risk of a possible null pointer dereference.
> >
> > Was largely found by using a static code analysis program called cppcheck.
>
> It is useful to
From: Rickard Strandqvist
Date: Sun, 1 Jun 2014 23:48:18 +0200
> From what I know, AND is faster then modulo.
> Not sure if this is worth changing though.
>
> Signed-off-by: Rickard Strandqvist
This code came from the IA-64 arch code, so you probably want to
fix either both or neither.
I'd
On 02.06.2014 03:38, Greg KH wrote:
>> Yes but... I should have avoided the term "GPIO".> No, you used the right
term :)
Sorry for using the right term :)
> No, I am not going to add custom ioctls to a single driver for this.
I did neither request nor expect that - did it sound that way?
>
This patch fixes build error under !CONFIG_CMA. dev_get_cma_area can be used
when CMA is disabled when the bellow patch is appied.
"arm: dma-mapping: add checking cma area initialized"
https://lkml.org/lkml/2014/5/22/35
arch/arm/mm/dma-mapping.c: In function 'atomic_pool_init':
On Mon, Jun 02, 2014 at 02:57:39AM +0200, Philipp Hachtmann wrote:
> On 01.06.2014 04:31, Greg KH wrote:
> >As they are GPIO pins on this device, it should be the subsystem that
> >controls it. That way, userspace programs that are used to talk to a
> >GPIO device will "just work", and not have
On Sun, 1 Jun 2014, Arnd Bergmann wrote:
> On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote:
> > > readonly if not in reality than in practice.
> >
> > For those (legacy) filesystems with a signed 32-bit timestamps, any
> > attempt to create a timestamp past Jan 19 03:14:06 2038 UTC should
(2014/06/02 4:25), Oleg Nesterov wrote:
> Purely cosmetic, no changes in .o,
>
> 1. As Jim pointed out arch_uprobe->def looks ambiguous, rename it to
>->dflt.
>
> 2. Add the comment into default_post_xol_op() to explain "regs->sp +=".
>
> 3. Remove the stale part of the comment in
On Sat, 2014-05-31 at 10:14 -0300, Peter Senna Tschudin wrote:
> This patch remove variables that are initialized with a constant,
> are never updated, and are only used as parameter of return.
> Return the constant instead of using a variable.
>
> Verified by compilation only.
>
> The
On 2014-06-01 19:42, Francois Romieu wrote:
> Udo van den Heuvel :
> [...]
>> On two boxes with rtl network chip I see connections going down.
>
> Do you notice netdev watchdog messages in the kernel log ?
I do not see messages that look like that.
>> 3.14.1 has the issue.
>
> Does it qualify
On 01.06.2014 04:31, Greg KH wrote:
As they are GPIO pins on this device, it should be the subsystem that
controls it. That way, userspace programs that are used to talk to a
GPIO device will "just work", and not have to be customized just for
this specific device and sysfs file.
So please
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/exynos.c between commits dfbdd3d55403 ("ARM: l2c:
exynos: remove cache size override"), 25a9ef63cd2b ("ARM: l2c: exynos:
convert to common l2c310 early resume functionality") and 15b0bc4041ba
("ARM: l2c:
Hello Weijie,
Thanks for resending.
Below are mostly nitpicks.
On Fri, May 30, 2014 at 04:34:44PM +0800, Weijie Yang wrote:
> Currently, we use a rwlock tb_lock to protect concurrent access to
> the whole zram meta table. However, according to the actual access model,
> there is only a small
On 05/30/2014 09:19 PM, Charles Keepax wrote:
> The higher levels of impedance have a higher minimum value than the
> first level. As the same value was used for all levels, higher impedances
> were reported with a very low level of accuracy. This patch applies the
> approriate lower threshold for
Hi Steven,
Thank you for your review and fixing my patch.
(2014/05/31 2:08), Steven Rostedt wrote:
On Fri, 30 May 2014 10:02:23 -0400
Steven Rostedt wrote:
This last part conflicts with my current 3.16 queue. You can see how it
does in my for-next repo. But I'll be pushing my latest with
On Sun, Jun 01, 2014 at 10:24:37AM +1000, Dave Chinner wrote:
> On Sat, May 31, 2014 at 05:37:52PM +0200, Arnd Bergmann wrote:
> > In my list at http://kernelnewbies.org/y2038, I found that almost
> > all file systems at least times until 2106, because they treat
> > the on-disk value as unsigned
Hi Linus !
Here's just one trivial patch to wire up sys_renameat2 which I
seem to have completely missed so far. (My test build scripts fwd me
warnings but miss the ones generated for missing syscalls).
Cheers,
Ben.
The following changes since commit 011e4b02f1da156ac7fea28a9da878f3c23af739:
This patch fixes the following sparse warnings:
dpc.c:65:21: warning: symbol 'acbyRxRate' was not declared. Should it be static?
dpc.c:272:9: warning: symbol 'MngWorkItem' was not declared. Should it be
static?
dpc.c:288:1: warning: symbol 'device_receive_frame' was not declared. Should it
be
On Sat, May 31, 2014 at 4:08 PM, Rickard Strandqvist
wrote:
> There is a risk that the variable will be used without being initialized.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/atm/fore200e.c |
This patch fixes the following sparse warnings:
skein_iv.h:23:11: warning: symbol 'SKEIN_256_IV_128' was not declared. Should
it be static?
skein_iv.h:31:11: warning: symbol 'SKEIN_256_IV_160' was not declared. Should
it be static?
skein_iv.h:39:11: warning: symbol 'SKEIN_256_IV_224' was not
On Fri, May 30, 2014 at 04:14:33PM +0800, Liu hua wrote:
> On 2014/5/29 8:13, Simon Horman wrote:
> > On Wed, May 28, 2014 at 09:49:56PM +0800, Liu Hua wrote:
> >> This patch deales with sparse memory model.
> >>
> >> For ARM32 platforms, different vendors may define different
> >>
This patch fixes the following sparse warnings:
skein_block.c:43:6: warning: symbol 'skein_256_process_block' was not declared.
Should it be static?
skein_block.c:252:6: warning: symbol 'skein_512_process_block' was not
declared. Should it be static?
skein_block.c:483:6: warning: symbol
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
gigabit Ethernet controller, an
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C
as well as SPI buses and PWM LEDs generically accessible from user
space and an LM95245 temperature sensor chip. The later five can also
be found on the
This patch fixes the following sparse warning in bpctl_mod.c:
warning: symbol 'bpvm_lock' was not declared. Should it be static?
Signed-off-by: James A Shackleford
---
drivers/staging/silicom/bpctl_mod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, Jun 02, 2014 at 12:01:46AM +0100, Ken Moffat wrote:
> > Naively, since the defconfigs are bundled with the kernel, that could
> > fall under GPLv2-only implicitly, but lacking any explicit copyright
> > headers makes this interesting (arch/*/configs/* contain lots of files,
> > no
On 06/01/2014 05:23 AM, Oren Twaig wrote:
> Hi Prarit,
>
> See below,
>
> On 05/30/2014 02:43 PM, Prarit Bhargava wrote:
>> I have a system on which I have disabled threading in the BIOS, and I am
>> booting
>> the kernel with the option "idle=poll".
>>
>> The kernel displays
>>
>> process:
On Sun, Jun 01, 2014 at 01:43:01AM +, Robin H. Johnson wrote:
> (Please CC me on replies, not subscribed to LKML)
>
> Hi,
>
> Somewhat of an odd question, but none of the files in question seem to
> have a copyright header on them...
>
> For a kernel .config file, either from one of the
On Sun, Jun 01, 2014 at 10:02:04PM +, Matthew Garrett wrote:
> On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote:
> > On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
> > wrote:
> > > Yeah, it seems I don't need the suspend quirk - the NHI is still there
> > > without it. I still think
On Sun, 1 Jun 2014 13:30:43 +0200, Rickard Strandqvist
wrote:
> There is a risk for memory leak in when something unexpected happens
> and the function returns.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
Hi Christian!
Yes! I mail about this for the first time in early May, but ther were
many other faults in the design of my patch, had several different
types of errors in the same path etc.
So good that they have already been solved then :)
Best regards
Rickard Strandqvist
2014-06-01 23:50
On Sun, 2014-06-01 at 22:42 +0200, Andreas Noever wrote:
> Just to check: Did they split up the device ids? Is 0x156d for the
> bridges and 0x156c for the NHI?
Yes. Some kind of progress. I did notice that the Apple driver binds to
all devices with the system peripheral class, vendor 8086 and
On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote:
> On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
> wrote:
> > Yeah, it seems I don't need the suspend quirk - the NHI is still there
> > without it. I still think we should make the quirk general rather than
> > tying it to the machines,
On Sun, 1 Jun 2014 13:32:20 +0200, Rickard Strandqvist
wrote:
> There is a risk for memory leak in when something unexpected happens
> and the function returns.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
This
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/sparc/kernel/smp_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
index
On Sun, Jun 01, 2014 at 11:30:03PM +0200, Peter Zijlstra wrote:
> On Sun, Jun 01, 2014 at 04:46:26PM -0400, John David Anglin wrote:
> > On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
> >
> > >>If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg
> > >>at
> > >>the same time,
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kernel/smpboot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kernel/patch.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/patch.c b/arch/ia64/kernel/patch.c
index
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kernel/palinfo.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index
Instead of re-implementing part of fs/fs-writeback.c, use a proposed
net ->writeback super operation to drive delta writeback. For each
inode that is cleaned, call inode_writeback_done(inode). For each
inode that will be kept dirty in cache, call inode_writeback_touch
so that the inode appears
Hi,
This is the first of four core changes we would like for Tux3. We
start with a hard one and suggest a simple solution.
The first patch in this series adds a new super operation to write
back multiple inodes in a single call. The second patch applies to
our linux-tux3 repository at
On Sun, Jun 01, 2014 at 04:46:26PM -0400, John David Anglin wrote:
> On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
>
> >>If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg
> >>at
> >>the same time, you break it. ACCESS_ONCE doesn't take the hashed
> >>spinlock,
> >>so, in
Hi Dan
I agree, this looks strange.
Have been looking for a while in history with, to see if the code has
been removed. I start my search using cppcheck for over three months
ago.
But could not find anything. Sorry about that :-(
But I'll make a patch that completely removes testing variable
On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
If you write to some variable with ACCESS_ONCE and use cmpxchg or
xchg at
the same time, you break it. ACCESS_ONCE doesn't take the hashed
spinlock,
so, in this case, cmpxchg or xchg isn't really atomic at all.
And this is really the first
On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
wrote:
> On Sun, 2014-06-01 at 12:11 +0200, Andreas Noever wrote:
>> On Sun, Jun 1, 2014 at 1:51 AM, Matthew Garrett
>> wrote:
>> > This seems to be working well on my MBP. It appears to broadly work on
>> > my Mac Pro, which has Thunderbolt 2
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also, a label is done away with and err2 and err3 renamed.
The following Coccinelle semantic patch was used for making the change:
On Sun, Jun 1, 2014 at 6:13 PM, Matthew Garrett
wrote:
> Adding extra device IDs is enough to get this working on the second-gen
> Thunderbolt controller in the Mac Pro.
>
> Signed-off-by: Matthew Garrett
> ---
> drivers/pci/quirks.c | 2 ++
> drivers/thunderbolt/nhi.c| 5 +
>
On Sun, Jun 01, 2014 at 03:28:35PM +0200, Rickard Strandqvist wrote:
> There is a risk that the variable will be used without being initialized.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
I've looked at the code, but I don't see this variable
Perhaps we should make this a kernel command line option instead, with the
settings: error out on outside the standard window, or a date indicating the
earliest date that should be recognized and do windowing (0 for no windowing,
1970 for retconning the Unix epoch as unsigned...)
But again,
On Sat, May 17, 2014 at 07:14:08PM +0200, Rickard Strandqvist wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
It is useful to put the output of the analyzer here.
>
> Signed-off-by:
There is a risk that the variables will be used without being initialized.
Have also moved variable to the part of the code where it is used.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
> Feel free to adap my patch or comments and commit. Or wait a few weeks for
> when I have a sponsor to split and update the patch.
OK, I'll hope you can make it for 3.17. Thanks!
signature.asc
Description: Digital signature
In this case the wrong variable is used, which has never been initialized.
This will lead to a serious error.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/power/ab8500_fg.c |4 ++--
1 file changed, 2
On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote:
> > readonly if not in reality than in practice.
>
> For those (legacy) filesystems with a signed 32-bit timestamps, any
> attempt to create a timestamp past Jan 19 03:14:06 2038 UTC should be
> (silently) clamped to 0x7fff and that
1 - 100 of 592 matches
Mail list logo
