Updating LED state requires access to regmap and therefore we may sleep,
so we could not do that directly form set_brightness() method.
Historically we used private work to adjust the brightness, but with the
introduction of set_brightness_blocking() we no longer need it.
As a bonus, not having
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for
From: John Hubbard
Hi,
It seems about time to post these initial patches: I think we have pretty
good consensus on the concept and details of the put_user_pages() approach.
Therefore, here are the first two patches, to get started on converting the
get_user_pages() call sites to use
From: John Hubbard
For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()
This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:
1) Provide
On Wed, 6 Feb 2019, Dmitry Safonov wrote:
>
> @@ -1721,9 +1722,16 @@ long hrtimer_nanosleep(const struct timespec64 *rqtp,
> {
> struct restart_block *restart;
> struct hrtimer_sleeper t;
> + struct timespec64 tp;
> int ret = 0;
> u64 slack;
>
> + if (!(mode &
Yes, we should not reset the DMA ops before releasing all resources:
Acked-by: Christoph Hellwig
On Thu, Feb 07, 2019 at 03:36:11PM +0200, Gilad Ben-Yossef wrote:
> We were enabling autosuspend, which is using data set by the
> hash module, prior to the hash module being inited, casuing
> a crash on resume as part of the startup sequence if the race
> was lost.
>
> This was never a real
On Thu, Feb 07, 2019 at 03:44:15PM +0200, Gilad Ben-Yossef wrote:
> The best-laid plans of mice and men often go awry.
> Remove Yael C. as co-maintainer as she moved on to other endeavours.
>
> Signed-off-by: Gilad Ben-Yossef
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
Patch
On Thu, Jan 31, 2019 at 11:51:35PM -0800, Eric Biggers wrote:
> Hello,
>
> Crypto algorithms must produce the same output for the same input
> regardless of data layout, i.e. how the src and dst scatterlists are
> divided into chunks and how each chunk is aligned. Request flags such
> as
On Wed, Jan 30, 2019 at 03:39:10PM +0100, Stephan Mueller wrote:
> Am Mittwoch, 30. Januar 2019, 11:08:54 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
> > I'm still not convinced why this needs to go into the crypto API
> > instead of being hosted in a helper which should achieve pretty
> > much
On Wed, Jan 30, 2019 at 08:57:52PM +, Singh, Brijesh wrote:
> A kexec reboot may leave the firmware in INIT or WORKING state.
> Currently, we issue PLATFORM_INIT command during the probe without
> checking the current state. The PLATFORM_INIT command fails if the
> FW is already in INIT state.
On Thu, Feb 07, 2019 at 09:46:23AM -0800, Yizhuo wrote:
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by:
On Mon, Jan 28, 2019 at 07:01:18PM -0500, Christopher Diaz Riveros wrote:
> Fixes coccinnelle alerts:
>
> /crypto/testmgr.c:2112:13-20: WARNING opportunity for kmemdup
> /crypto/testmgr.c:2130:13-20: WARNING opportunity for kmemdup
> /crypto/testmgr.c:2152:9-16: WARNING opportunity for kmemdup
>
On Thu, 2019-02-07 at 22:26 +, Jason Gunthorpe wrote:
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists
> w/o
> backing pages") introduced the sg_page_iter_dma_address() function
> without
> providing a way to use it in the general case. If the sg_dma_len() is
> not
>
From: Guennadi Liakhovetski
Device links are refcounted, device_link_remove() has to be called as
many times as device_link_add().
Signed-off-by: Guennadi Liakhovetski
---
Resending with the "PATCH" subject line modifier.
drivers/regulator/core.c | 10 +-
1 file changed, 1
On Fri, 08 Feb 2019 03:18:23 +0100,
Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> sound/soc/xilinx/xlnx_formatter_pcm.c: In function 'xlnx_formatter_pcm_new':
>
On Thu, Feb 07, 2019 at 09:50:30PM -0800, Mike Kravetz wrote:
> On 2/7/19 6:31 PM, Naoya Horiguchi wrote:
> > On Thu, Feb 07, 2019 at 10:50:55AM -0800, Mike Kravetz wrote:
> >> On 1/30/19 1:14 PM, Mike Kravetz wrote:
> >>> +++ b/fs/hugetlbfs/inode.c
> >>> @@ -859,6 +859,16 @@ static int
Hi Enrico,
On Thu, Feb 07, 2019 at 06:05:31PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Instead of hardcoding the input name to the driver name ('gpio-keys-polled'),
> allow the passing a name via platform data ('name' field was already present),
> but default to old behaviour in case of
Space savings on x86_64:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-29 (-29)
Function old new delta
strncmp 67 38 -29
Space savings on arm:
add/remove: 0/0 grow/shrink: 0/1
Hi all,
After merging the apparmor tree, today's linux-next build (powerpc
allyesconfig) failed like this:
security/apparmor/policy_unpack.c: In function 'deflate_compress':
security/apparmor/policy_unpack.c:1064:4: error: implicit declaration of
function 'vfree'; did you mean 'kfree'?
Hello Again Lee,
After a good night sleep few things came to my mind =)
On Thu, Feb 07, 2019 at 02:00:53PM +, Lee Jones wrote:
> On Thu, 07 Feb 2019, Matti Vaittinen wrote:
>
> > +
> > +static struct mfd_cell bd70528_mfd_cells[] = {
> > + { .name = "bd70528-pmic", },
> > + { .name =
On Thu, Feb 07, 2019 at 06:03:03PM -0500, Sven Van Asbroeck wrote:
> On Thu, Feb 7, 2019 at 5:27 PM Dmitry Torokhov
> wrote:
> >
> > + flush_work(>tx_work.work);
>
> Would cancel_work_sync() be better than flush_work() ?
No, because we want to have interrupt and gpios in a consistent
Hi Linus,
Here are a handful of XFS fixes to fix a data corruption problem, a
crasher bug, and a deadlock. It merged cleanly against this morning's
master, so please let me know if you encounter any problems.
--D
The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
On Thu, Feb 7, 2019 at 9:19 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 07, 2019 at 03:54:58PM -0800, Dan Williams wrote:
>
> > > The only production worthy way is to have the FS be a partner in
> > > making this work without requiring revoke, so the critical RDMA
> > > traffic can operate safely.
On 07-02-19, 14:37, Ulf Hansson wrote:
> I think we also need to consider cross SoC drivers. One SoC may have
> both clocks and OPPs to manage, while another may have only clocks.
We already have that case with CPUs as well and dev_pm_opp_set_rate()
takes care of it.
> Even it this may be fairly
Fri, Feb 08, 2019 at 04:42:41AM CET, gust...@embeddedor.com wrote:
>One of the more common cases of allocation size calculations is finding
>the size of a structure that has a zero-sized array at the end, along
>with memory for some number of elements for that array. For example:
>
>struct foo {
>
On 06-02-19, 23:58, Stephen Boyd wrote:
> Quoting Viresh Kumar (2019-01-31 01:23:49)
> > FWIW, I suggested exactly this solution sometime back [1]
> >
> > - Drivers need to use two API sets to change clock rate (OPP helpers)
> > and enable/disable them (CLK framework helpers) and this leads us
Sander Eikelenboom wrote:
> L.S.,
>
> While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression
> with NAT.
> (using an nftables firewall with NAT and connection tracking).
>
> Unfortunately it isn't too obvious since no errors are logged, but on clients
> it
> causes
On Mon, Feb 04, 2019 at 11:01:06AM +1100, Stephen Rothwell wrote:
> Hi Herbert,
>
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/crypto/qat/qat_common/adf_transport.c: In function
> 'adf_init_etr_data':
>
On Wed, Feb 06, 2019 at 09:30:29AM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 6, 2019 at 8:47 AM Greg KH wrote:
> >
> > On Tue, Feb 05, 2019 at 02:12:31PM -0500, Sven Van Asbroeck wrote:
> > > On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
> > > >
> > > >
> > > > It really should happen when the
On 07-02-19, 13:22, Marek Szyprowski wrote:
> Dear All,
>
> Recent commit 9ac6cb5fbb17 ("i2c: add suspended flag and accessors for
> i2c adapters") added a visible warning for an attempt to do i2c transfer
> over a suspended i2c bus. This revealed a long standing issue in the
> cpufreq-dt driver,
On Fri, Feb 08, 2019 at 11:43:55AM +0530, Naresh Kamboju wrote:
> On Thu, 7 Feb 2019 at 17:12, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 4.4.174 release.
> > There are 34 patches in this series, all will be posted as a response
> > to this one. If
On 02/08/2019 09:54 AM, Matthew Wilcox wrote:
> On Fri, Feb 08, 2019 at 07:43:57AM +0530, Anshuman Khandual wrote:
>> How non-standard huge pages can be supported for THP
>>
>> - THP starts recognizing non standard huge page (exported by arch) like
>> HPAGE_CONT_(PMD|PTE)_SIZE
>> -
On Wed, Feb 06, 2019 at 11:28:32AM +0100, Petr Mladek wrote:
> On Tue 2019-02-05 09:59:33, Josh Poimboeuf wrote:
> > On Tue, Feb 05, 2019 at 03:33:28AM +0900, Alice Ferrazzi wrote:
> > > From: Alice Ferrazzi
> > >
> > > As a result of an unsupported operation is better to use EOPNOTSUPP
> > > as
bounds-tests
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Summary
kernel: 4.4.174-rc1
git repo: https://git.linaro.org/lkft/arm64-stab
On Thu, Feb 07, 2019 at 02:01:52PM -0800, ndesaulni...@google.com wrote:
> -O2 enables tail merging of string table strings.
>
> For arm64:
> 0.34% size improvement with lld -O2 over lld for vmlinux.
> 3.30% size improvement with lld -O2 over lld for Image.lz4-dtb.
>
> Link:
Now that we have MAP_SHARED, MAP_PRIVATE and MAP_SHARED_VALIDATE on all
architectures, it probably makes sense to de-duplicate these
and put them into a common header.
Please review and consider merging though the generic tree.
Build tested on x86 only. Has been in linux-next for a while now.
Use linux/mman.h to make sure we get all mmap flags we need.
Signed-off-by: Michael S. Tsirkin
---
include/drm/drmP.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bdb0d5548f39..a3184416ddc5 100644
--- a/include/drm/drmP.h
Use linux/mman.h to make sure we get all mmap flags we need.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/mm/mpx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index de1851d15699..c805db6236b4 100644
--- a/arch/x86/mm/mpx.c
+++
Now that we have 3 mmap flags shared by all architectures,
let's move them into the common header.
This will help discourage future architectures from duplicating code.
Signed-off-by: Michael S. Tsirkin
---
arch/alpha/include/uapi/asm/mman.h | 4 +---
arch/mips/include/uapi/asm/mman.h
Now that we have 3 mmap flags shared by all architectures,
let's move them into the common header.
This will help discourage future architectures from duplicating code.
Signed-off-by: Michael S. Tsirkin
---
arch/alpha/include/uapi/asm/mman.h | 4 +---
arch/mips/include/uapi/asm/mman.h
FATAL: drivers/rtc/rtc-x1205: struct of_device_id is not terminated with a NULL
entry!
Caused by commit
08bb868190c2 ("rtc: x1205: Add DT probing support")
I have used the rtc tree from next-20190207 for today.
--
Cheers,
Stephen Rothwell
pgpdC66xO48v_.pgp
Description: OpenP
On Thu, Feb 07, 2019 at 09:01:41PM -0800, Andrew Morton wrote:
> On Thu, 7 Feb 2019 14:11:16 -0500 "Michael S. Tsirkin"
> wrote:
>
> > mm/debug-pagealloc.c is no more, so of course header now needs to be
> > updated. This seems like something checkpatch should be
> > able to catch - worth
On 2/7/19 6:31 PM, Naoya Horiguchi wrote:
> On Thu, Feb 07, 2019 at 10:50:55AM -0800, Mike Kravetz wrote:
>> On 1/30/19 1:14 PM, Mike Kravetz wrote:
>>> +++ b/fs/hugetlbfs/inode.c
>>> @@ -859,6 +859,16 @@ static int hugetlbfs_migrate_page(struct address_space
>>> *mapping,
>>> rc =
On Thu, Feb 07, 2019 at 02:01:51PM -0800, ndesaulni...@google.com wrote:
> This is needed because clang doesn't select which linker to use based on
> $LD but rather -fuse-ld=$(LD). This is problematic especially for
> cc-ldoption, which checks for linker flag support via invoking the
> compiler,
On Wed, 6 Feb 2019 15:10:16 -0800 john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> This combines the common elements of these routines:
>
> page_cache_get_speculative()
> page_cache_add_speculative()
>
> This was anticipated by the original author, as shown by the comment
> in
On Thu, Feb 07, 2019 at 02:01:50PM -0800, ndesaulni...@google.com wrote:
> This causes an issue when trying to build with `make LD=ld.lld` if
> ld.lld and the rest of your cross tools aren't in the same directory
> (ex. /usr/local/bin) (as is the case for Android's build system), as the
>
>
> int arch_update_cpu_topology(void)
> {
> - return numa_update_cpu_topology(true);
> + int changed = topology_changed;
> +
> + topology_changed = 0;
> + return changed;
> }
>
Do we need Powerpc override for arch_update_cpu_topology() now? That
topology_changed sometime
On Thu, Feb 07, 2019 at 07:57:20PM -0500, Mathieu Desnoyers wrote:
>
> - ndesaulni...@google.com wrote:
> > Similar to how we differentiate between CONFIG_CC_IS_GCC and
> > CONFIG_CC_IS_CLANG, add CONFIG_LD_IS_BFD, CONFIG_LD_IS_GOLD, and
> > CONFIG_LD_IS_LLD.
> >
> > This simiplifies patches
On Thu, 7 Feb 2019 11:27:50 +0100 Jan Kara wrote:
> On Fri 01-02-19 09:19:04, Dave Chinner wrote:
> > Maybe for memcgs, but that's exactly the oppose of what we want to
> > do for global caches (e.g. filesystem metadata caches). We need to
> > make sure that a single, heavily pressured cache
On Thu, Feb 7, 2019 at 10:17 PM Matthew Wilcox wrote:
>
> On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote:
> > Just thought to take opinion for documentation before placing it in v3.
> > Does it looks fine ?
> >
> > +/**
> > + * __vm_insert_range - insert range of kernel pages
On Thu, Feb 07, 2019 at 03:54:58PM -0800, Dan Williams wrote:
> > The only production worthy way is to have the FS be a partner in
> > making this work without requiring revoke, so the critical RDMA
> > traffic can operate safely.
>
> ...belies a path forward. Just swap out "FS be a partner"
On Thu, Feb 07, 2019 at 02:01:49PM -0800, ndesaulni...@google.com wrote:
> Similar to how we differentiate between CONFIG_CC_IS_GCC and
> CONFIG_CC_IS_CLANG, add CONFIG_LD_IS_BFD, CONFIG_LD_IS_GOLD, and
> CONFIG_LD_IS_LLD.
>
> This simiplifies patches to Makefiles that need to do different things
On 2/8/2019 1:58 AM, Mathieu Poirier wrote:
On Thu, 31 Jan 2019 at 17:55, Sai Prakash Ranjan
wrote:
Add support for coresight CPU debug module on Qualcomm
Kryo CPUs. This patch adds the UCI entries for Kryo CPUs
found on MSM8996 which shares the same PIDs as ETMs.
[..]
I have reviewed
Ivan Delalande writes:
> On Tue, Feb 05, 2019 at 01:11:19PM -0800, Andrew Morton wrote:
>> On Mon, 4 Feb 2019 18:53:08 -0800 Ivan Delalande wrote:
>> > --- a/fs/exec.c
>> > +++ b/fs/exec.c
>> > @@ -1660,7 +1660,12 @@ int search_binary_handler(struct linux_binprm *bprm)
>> >if
Hi,
On 08/02/19 2:56 AM, Bjorn Helgaas wrote:
> On Thu, Feb 07, 2019 at 04:39:23PM +0530, Kishon Vijay Abraham I wrote:
>> Now that Keystone started using it's own msi_irq_chip, remove
>> Keystone specific callback function defined in dw_pcie_host_ops.
>
> s/it's/its/
> s/callback
On 2/8/2019 1:56 AM, Mathieu Poirier wrote:
On Thu, 31 Jan 2019 at 17:54, Sai Prakash Ranjan
wrote:
I am good with this patch but there isn't much I can do with it until
Mike's patchset has been merged. Please submit again when that has
been done.
Sure, thanks.
--
QUALCOMM INDIA, on
Hi All,
On 08/02/2019 6.55, Vesa Jääskeläinen wrote:
Hi All,
On 31/01/2019 0.35, Pavel Machek wrote:
On Wed 2019-01-30 12:30:05, Dan Murphy wrote:
Add a documentation of LED Multicolor LED class specific
sysfs attributes.
No, sorry. This does not most of the requirements.
Hi all,
After commit 8c5ad0dae93c ("igc: Add ethtool support"), Clang warns:
drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: warning: variable
'igc_priv_flags_strings' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const char
Hi Roger,
On 07/02/19 7:52 PM, Roger Quadros wrote:
>
>
> On 07/02/19 14:19, Kishon Vijay Abraham I wrote:
>> Hi Roger,
>>
>> On 07/02/19 4:56 PM, Roger Quadros wrote:
>>>
>>>
>>> On 06/02/19 13:07, Kishon Vijay Abraham I wrote:
AM654x has two SERDES instances. Each instance has three
On Thu, 7 Feb 2019 14:11:16 -0500 "Michael S. Tsirkin" wrote:
> mm/debug-pagealloc.c is no more, so of course header now needs to be
> updated. This seems like something checkpatch should be
> able to catch - worth looking into?
>
> Cc: triv...@kernel.org
> Cc: linux...@kvack.org
> Cc: Linus
Clang warns:
sound/soc/codecs/jz4725b.c:177:14: warning: duplicate 'const' declaration
specifier [-Wduplicate-decl-specifier]
static const SOC_VALUE_ENUM_SINGLE_DECL(jz4725b_codec_adc_src_enum,
^
include/sound/soc.h:356:2: note: expanded from macro
'SOC_VALUE_ENUM_SINGLE_DECL'
Hi All,
On 31/01/2019 0.35, Pavel Machek wrote:
On Wed 2019-01-30 12:30:05, Dan Murphy wrote:
Add a documentation of LED Multicolor LED class specific
sysfs attributes.
No, sorry. This does not most of the requirements.
Pavel
GPIO pin mapping taken from NetGear NV+ v2 5.3.13 kernel sources[1]
(see arch/arm/plat-feroceon/mv_hal/rtc/ext_rtc/usiLCD.c).
1. https://www.downloads.netgear.com/files/GPL/RND_5.3.13_WW.src.zip
Signed-off-by: David Coles
---
.../boot/dts/kirkwood-netgear_readynas_nv+_v2.dts | 14
net/core/ethtool.c:3023:19: warning: address of array
'ext_m_spec->h_dest' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (ext_m_spec->h_dest) {
~~ ^~
h_dest is an array, it can't be null so remove this check.
Fixes: eca4205f9ec3
Hi Lorenzo,
On 07/02/19 10:18 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 07, 2019 at 04:39:21PM +0530, Kishon Vijay Abraham I wrote:
>> Platforms using Designware IP uses dw_pci_msi_bottom_irq_chip for
>> configuring the MSI controller logic within the Designware IP. However
>> certain platforms
On Thu, Feb 07, 2019 at 04:55:37PM +, Christopher Lameter wrote:
> One approach that may be a clean way to solve this:
> 3. Filesystems that allow bypass of the page cache (like XFS / DAX) will
>provide the virtual mapping when the PIN is done and DO NO OPERATIONS
>on the longterm
On 2/8/2019 1:17 AM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2019-02-06 22:57:12)
3) How do we handle devices that already have power-domains specified in
DT? The opp binding for required-opps doesn't let us specify the power
domain to target, instead it assumes that whatever power
On Thu, Jan 31, 2019 at 02:58:50PM +, Julien Thierry wrote:
> Instead disabling interrupts by setting the PSR.I bit, use a priority
> higher than the one used for interrupts to mask them via PMR.
>
> When using PMR to disable interrupts, the value of PMR will be used
> instead of PSR.[DAIF]
Hi,
On 07/02/19 9:14 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 07, 2019 at 04:39:18PM +0530, Kishon Vijay Abraham I wrote:
>> ks_pcie_get_irq_controller_info() was used to configure both MSI and
>> legacy interrupt. This will prevent MSI or legacy interrupt specific
>> intializations. Add
Hi Lorenzo,
On 07/02/19 9:45 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 07, 2019 at 04:39:17PM +0530, Kishon Vijay Abraham I wrote:
>> The legacy interrupt handler directly checks the IRQ_STATUS register
>> corresponding to a interrupt line inorder to invoke generic_handle_irq.
>>
>> While this
On Thu, Feb 7, 2019 at 11:28 PM Jason Gunthorpe wrote:
>
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> backing pages") introduced the sg_page_iter_dma_address() function without
> providing a way to use it in the general case. If the sg_dma_len() is not
> equal to
On Thu, Feb 7, 2019 at 11:33 PM Sven Van Asbroeck wrote:
>
> On Thu, Feb 7, 2019 at 5:21 PM Dmitry Torokhov
> wrote:
> >
> > > ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> > > of INIT_WORK/INIT_DELAYED_WORK initialized here
> >
> > This is not as simple.
> >
>
> PS If
s */
> + bool timeout_adjusted;
> + unsigned long duration[TPM_NUM_DURATIONS]; /* jiffies */
> + bool duration_adjusted;
> +
> + struct dentry *bios_dir[TPM_NUM_EVENT_LOG_FILES];
> +
> + const struct attribute_group *groups[3];
> + unsigned int grou
On Fri, Feb 08, 2019 at 07:43:57AM +0530, Anshuman Khandual wrote:
> How non-standard huge pages can be supported for THP
>
> - THP starts recognizing non standard huge page (exported by arch) like
> HPAGE_CONT_(PMD|PTE)_SIZE
> - THP starts operating for either on HPAGE_PMD_SIZE or
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
On 2/7/19 5:26 PM, Jerry Hoemann wrote:
On Sat, Feb 02, 2019 at 09:55:29AM +0500, Ivan Mironov wrote:
On Tue, 2019-01-15 at 19:27 -0700, Jerry Hoemann wrote:
On Mon, Jan 14, 2019 at 07:36:14AM +0500, Ivan Mironov wrote:
Somehow I missed the whole pretimout thing when reading about the
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
Currently the only way to clear the mfc cache was to delete the entries
one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which will clear the multicast forwarding
cache on the socket without destroying the socket. The new socket
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Using the flags MRT_FLUSH_ENTRIES and MRT_FLUSH_VIFS, all multicast
entries can be cleared, all
On Wed, 2019-02-06 at 13:12 -0800, Dan Williams wrote:
> Before people get too excited this isn't a proposal to kill DAX. The
> topic proposal is a discussion to resolve lingering open questions
> that currently motivate ext4 and xfs to scream "EXPERIMENTAL" when the
> current DAX facilities are
On 2/7/19 10:00 PM, Joe Perches wrote:
> On Thu, 2019-02-07 at 18:28 -0600, Gustavo A. R. Silva wrote:
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements
On Thu, 2019-02-07 at 18:40 -0600, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
>
On Thu, 2019-02-07 at 18:28 -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
On 1/31/19 8:11 AM, Chuck Lever wrote:
>
>
>> On Jan 30, 2019, at 7:46 PM, Gustavo A. R. Silva
>> wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
size = sizeof(struct foo) + count *
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
Jonathan Corbet writes:
> On Thu, 7 Feb 2019 17:03:15 +1100
> "Tobin C. Harding" wrote:
>
>> As discussed at LCA here is the start to the docs conversion for PowerPC
>> to RST.
>>
>> This applies cleanly on top of the mainline (5.20-rc5) and Jon's tree
>> (docs-next branch).
>>
>> I'm
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
size = sizeof(struct foo) + count *
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = alloc(sizeof(struct foo)
On Fri, 2019-02-08 at 04:09 +0100, Mike Galbraith wrote:
> On Thu, 2019-02-07 at 20:13 +0100, Michael Brunnbauer wrote:
> > hi,
> >
> > no replies to my mail. Any suggestions what I should do or where I
> > could ask for help?
>
> I'd suggest trying to capture events with something better than
On Thu, 2019-02-07 at 20:13 +0100, Michael Brunnbauer wrote:
> hi,
>
> no replies to my mail. Any suggestions what I should do or where I
> could ask for help?
I'd suggest trying to capture events with something better than an
incomplete screenshot, ie serial console, netconsole, anything that
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = alloc(sizeof(struct foo)
On 02/07/2019 09:02 PM, Robin Murphy wrote:
> On 07/02/2019 13:36, Oscar Salvador wrote:
>> On Wed, Feb 06, 2019 at 05:03:53PM +, Robin Murphy wrote:
>>> ARCH_MEMORY_PROBE is a useful thing for testing and debugging hotplug,
>>> but being able to exercise the (arguably trickier) hot-remove
Jann Horn writes:
> On Thu, Feb 7, 2019 at 10:22 AM Christophe Leroy
> wrote:
>> In powerpc code, there are several places implementing safe
>> access to user data. This is sometimes implemented using
>> probe_kernel_address() with additional access_ok() verification,
>> sometimes with
Due to:
- current implementation of l2cap_config_rsp() dropping BT
connection if sender of configuration response replied with unknown
option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
- current implementation of l2cap_build_conf_req() adding
L2CAP_CONF_RFC(0x04) option to initial
1 - 100 of 1097 matches
Mail list logo
