On 28 May 2014 18:09, Mimi Zohar wrote:
> (UEFI) secure boot provides a signature chain of trust rooted in
> hardware. The signature chain of trust includes the Machine Owner
> Keys(MOKs), which cannot be modified without physical presence.
>
> Instead of allowing public keys, with certificates
This series adds SMP support for two Broadcom mobile SoC families.
It uses CPU_METHOD_OF_DECLARE() so that SMP operations are assigned
using device tree rather than adding it to a machine definition in a
board file.
The enable method starts a secondary core by writing to a register
monitored by
This patch adds SMP support for BCM281XX and BCM21664 family SoCs.
This feature is controlled with a distinct config option such that
an SMP-enabled multi-v7 binary can be configured to run these SoCs
in uniprocessor mode. Since this SMP functionality is used for
multiple Broadcom mobile chip
Define nodes representing the two Cortex A9 CPUs in a bcm21644 SoC.
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm21664.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
index 08a44d4..a37ded1
Also explicitly set CONFIG_NR_CPUS to 2, limiting it to the most we
currently need.
Signed-off-by: Ray Jui
Signed-off-by: Alex Elder
---
arch/arm/configs/bcm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index
Broadcom mobile SoCs use a ROM-implemented holding pen for
controlled boot of secondary cores. A special register is
used to communicate to the ROM that a secondary core should
start executing kernel code. This enable method is currently
used for members of the bcm281xx and bcm21664 SoC
Define nodes representing the two Cortex A9 CPUs in a bcm28155 SoC.
Signed-off-by: Ray Jui
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm11351.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
The CoreNet Coherency Fabric is part of the memory subsystem on
some Freescale QorIQ chips. It can report coherency violations (e.g.
due to misusing memory that is mapped noncoherent) as well as
transactions that do not hit any local access window, or which hit a
local access window with an
Il giorno 30/mag/2014, alle ore 18:07, Tejun Heo ha scritto:
> Hello, Paolo.
>
> On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
>> this patchset introduces the last version of BFQ, a proportional-share
>> storage-I/O scheduler. BFQ also supports hierarchical scheduling with
>>
On Fri, May 30, 2014 at 04:00:17PM -0600, Bjorn Helgaas wrote:
> Thanks, I should have waited for you. I was assuming the merge window
> would open on Monday, and I hoped for a day or two in -next, but now
> it sounds like we might have an -rc8, so I needn't have been in such a
> hurry.
Bah, no
Error handling code in poseidon_probe() misses usb_put_intf()
and usb_put_dev().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/usb/tlg2300/pd-main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The bindings for CPU enable methods are defined in ".../arm/cpus.txt". As
additional 32-bit ARM CPUS are converted to use the "enable-method" CPU
property to imply a particular set of SMP operations to use, the list of these
methods is likely to become unwieldy. The current documentation already
On Thu, 22 May 2014 03:25:47 -
Thomas Gleixner wrote:
> Index: tip/kernel/locking/rtmutex.c
> ===
> --- tip.orig/kernel/locking/rtmutex.c
> +++ tip/kernel/locking/rtmutex.c
> @@ -256,6 +256,25 @@ static void
Il giorno 30/mag/2014, alle ore 17:46, Tejun Heo ha scritto:
> On Thu, May 29, 2014 at 11:05:42AM +0200, Paolo Valente wrote:
>> This patch boosts the throughput on NCQ-capable flash-based devices,
>> while still preserving latency guarantees for interactive and soft
>> real-time applications.
On Fri, May 30, 2014 at 3:46 PM, Borislav Petkov wrote:
> On Fri, May 30, 2014 at 11:01:03AM -0600, Bjorn Helgaas wrote:
>> On Tue, May 07, 2013 at 04:29:31PM -0700, Yinghai Lu wrote:
>> > We should assign unassigned resource before pci_bus_add_device.
>> >
>> > as late one will enable driver and
AFAICS the main use of syscall auditing is to get syscall
information for syscalls that are already causing another audit
message.
We don't need any of the fancy syscall auditing machinery for that,
though: we can just log this information directly. This should have
essentially no overhead and
syscall_in_syscall will return true if we're in a real syscall and
will return false if we're not in a syscall. If we're in a bad
syscall, the return value can vary.
The idea is to use this to come up with a much simpler replacement
for syscall auditing.
Signed-off-by: Andy Lutomirski
---
I've made no secret of the fact that I dislike syscall auditing. As far
as I can tell, the main technical (i.e. not compliance-related) use of
syscall auditing is to supply some useful context information to go
along with events like AVC denials.
CONFIG_AUDITSYSCALL is serious overkill to do
Il giorno 30/mag/2014, alle ore 17:37, Tejun Heo ha scritto:
> On Thu, May 29, 2014 at 11:05:33AM +0200, Paolo Valente wrote:
>> diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
>> index 768fe44..cdd2528 100644
>> --- a/include/linux/cgroup_subsys.h
>> +++
Il giorno 30/mag/2014, alle ore 17:39, Tejun Heo ha scritto:
> On Fri, May 30, 2014 at 11:37:18AM -0400, Tejun Heo wrote:
>> On Thu, May 29, 2014 at 11:05:33AM +0200, Paolo Valente wrote:
>>> diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
>>> index 768fe44..cdd2528
A maintenance release Git v1.9.4 is now available at the usual
places. This is expected to be the final maintenance release for
the 1.9 series, merging the remaining fixes that are relevant and
are already in 2.0.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The
From: Andi Kleen
The Intel events use a dot to separate event name and unit mask.
Allow dot in names in the scanner, and remove special handling
of dot as EOF. Also remove the hack in jevents to replace dot
with underscore. This way dotted events can be specified
directly by the user.
I'm not
From: Andi Kleen
When no JSON event file is specified automatically look
for a suitable file in ~/.cache/pmu-events. A "perf download" can
automatically add files there for the current CPUs.
This does not include the actual event files with perf,
but they can be automatically downloaded instead
From: Andi Kleen
I need a JSON parser. This adds the simplest JSON
parser I could find -- Serge Zaitsev's jsmn `jasmine' --
to the perf library. I merely converted it to (mostly)
Linux style and added support for non 0 terminated input.
The parser is quite straight forward and does not
copy any
From: Andi Kleen
Add a downloader to automatically download the right
files from a download site.
This is implemented as a script calling wget, similar to
perf archive. The perf driver automatically calls the right
binary. The downloader is extensible, but currently only
implements an Intel
From: Andi Kleen
Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.
Signed-off-by: Andi Kleen
---
tools/perf/util/cache.h | 1 +
From: Andi Kleen
Change pmu.c to allow descriptions of events and add interfaces
to add aliases. Used in the next patch.
Signed-off-by: Andi Kleen
---
tools/perf/util/pmu.c | 127 ++
1 file changed, 98 insertions(+), 29 deletions(-)
diff --git
From: Andi Kleen
Fix the logic to allow overriding event default periods with -c or -F
on the command line. I'm not sure I understand this if() fully, but
this change makes all cases I tested work (tracepoint with default, default,
,-c, -F)
This fixed specifying -c / -F with json event list
[v2: Review feedback addressed and some minor improvements]
[v3: More review feedback addressed and handle test failures better.
Ported to latest tip/core.]
[v4: Addressed Namhyung's feedback]
[v5: Rebase to latest tree. Minor description update.]
perf has high level events which are useful in
From: Andi Kleen
Add a simple test case to perf test that runs perf download and parses
all the events. This needs adding an all event iterator to pmu.c
v2: Rename identifiers
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.perf| 1 +
tools/perf/tests/aliases.c | 58
From: Andi Kleen
Add a parser for Intel style JSON event files. This allows
to use an Intel event list directly with perf. The Intel
event lists can be quite large and are too big to store
in unswappable kernel memory.
The parser code knows how to convert the JSON fields
to perf fields. The
On Fri, May 30, 2014 at 11:01:03AM -0600, Bjorn Helgaas wrote:
> On Tue, May 07, 2013 at 04:29:31PM -0700, Yinghai Lu wrote:
> > We should assign unassigned resource before pci_bus_add_device.
> >
> > as late one will enable driver and create sysfs file that will need
> > pci io resources from
On Fri, May 30, 2014 at 08:48:41AM -0500, Christoph Lameter wrote:
> On Thu, 29 May 2014, Andrew Morton wrote:
>
> > >
> > > if (!nodemask && gfp_zone(gfp_mask) < policy_zone)
> > > nodemask = _states[N_ONLINE];
> >
> > OK, thanks, I made the patch go away for now.
> >
>
> And
From: Andi Kleen
perf stat -rX prints the stddev for multiple measurements.
Just looking at the stddev for judging the quality of the data
is a bit dangerous The simplest sanity check is to just look
at a simple plot. This patchs add a sparkline to the end
of the measurements to make it simple
On Thu, 22 May 2014 03:25:42 -
Thomas Gleixner wrote:
> The tester has been broken for quite some time. It's possible to fix
> it, but the main reason for having it in the kernel was the lock steal
> mechanism in the rtmutex code. That's gone, so we can implement a
> stateful correctness
On Fri, May 30, 2014 at 02:16:06PM -0700, Tony Luck wrote:
> On Fri, May 30, 2014 at 3:07 AM, Borislav Petkov wrote:
> > Please elaborate, what conditions? DIMM silk screen labels or so? Maybe
> > we can generate a mapping between text labels and indices and we can
> > dump the indices in the
Linus Torvalds writes:
> From a quick glance at the frame usage, some of it seems to be gcc
> being rather bad at stack allocation, but lots of it is just nasty
> spilling around the disgusting call-sites with tons or arguments. A
> _lot_ of the stack slots are marked as "%sfp" (which is gcc'ese
On Fri, May 30, 2014 at 08:50:56AM -0500, Christoph Lameter wrote:
> On Thu, 29 May 2014, David Rientjes wrote:
>
> > When I said that my point about mempolicies needs more thought, I wasn't
> > expecting that there would be no discussion -- at least _something_ that
> > would say why we don't
On Fri, May 30, 2014 at 3:07 AM, Borislav Petkov wrote:
> Please elaborate, what conditions? DIMM silk screen labels or so? Maybe
> we can generate a mapping between text labels and indices and we can
> dump the indices in the tracepoint and do the mapping back to strings in
> userspace...?
The
On Fri, May 30, 2014 at 1:01 PM, Arnd Bergmann wrote:
> pstore uses timestamps encoded in a string as seconds, but on 32-bit systems
> cannot go beyond year 2038 because of the limits of struct timespec.
>
> This converts the pstore code to use the new struct inode_time for timestamps.
>
>
On Fri, 2014-05-30 at 09:13 -0500, Roger Heflin wrote:
> Do enough smartcmds and the entire board (all 4 ports) locked up and
> required a reboot, I quit doing smartcmds and stability went way up,
> but it was still not 100% stable.
Any chance you can give me an example of "enough smartcmds" ? IE
On Fri, 2014-05-30 at 09:58 -0400, Jérôme Carretero wrote:
> Weird (I hadn't seen that you reported the 9235 working...), I have
> IOMMU problems with a 9235...
>
> What system are you running it on (when you say "power box", is it a
> beefy x86 computer or literally a PowerPC)?
> For me, AMD
Move the definition of __peri_clk_init() up in "clk-kona.c", in
preparation for the next patch (so it's defined before it's needed).
Move kona_ccu_init() and __kona_clk_init() as well.
Done as a separate patch so doing so doesn't obscure other changes.
Signed-off-by: Alex Elder
---
Currently only peripheral clocks are supported for Broadcom platforms
that use Kona style CCUs for clocking. This series adds support for
bus clocks as well.
One motivation for doing this is that there exist peripheral clocks
that cannot be configured without having first enabled a related bus
The last thing done for CCU setup is a call to kona_ccu_init().
This locks and enables write access on the CCU, then calls
__kona_clk_init() for all of the clocks it provides. The purpose of
this was to get or set the initial state of all the registers
related to each clock.
There's no reason to
Use a counter rather than a Boolean to track whether write access to
a CCU has been enabled or not. This will allow more than one of
these requests to be nested.
Note that __ccu_write_enable() and __ccu_write_disable() calls all
come in pairs, and they are always surrounded immediately by calls
Add bus clock support. A bus clock has a subset of the components
present in a peripheral clock (again, all optional): a gate; CCU
policy management bits; and if needed, bits to control hysteresis.
Signed-off-by: Alex Elder
---
drivers/clk/bcm/clk-kona-setup.c | 96
Allow a clock to specify a "prerequisite" clock, identified by its
name. The prerequisite clock must be prepared and enabled before a
clock that depends on it is used. In order to simplify locking, we
require a clock and its prerequisite to be associated with the same
CCU. (We'll just
Add the bus clock named "bsc3_apb" to the list of those provided by
the slave CCU.
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm11351.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index
Define the bus clock "bsc3_apb". This bus clock has to be managed
using the CCU policy mechanism, so add the definitions required for
that to the clock and its CCU.
This one bus clock in particular is defined because it is needed
by peripheral clock "bsc3". Our boot loader does not properly
On 30 May 2014 16:04, Dietmar Eggemann wrote:
> On 23/05/14 16:52, Vincent Guittot wrote:
>> power_orig is only changed for system with a SMT sched_domain level in order
>> to
>> reflect the lower capacity of CPUs. Heterogenous system also have to reflect
>> an
>> original capacity that is
This patch adds support for end of transaction (EOT) and notify when done (NWD)
hardware descriptor flags.
The EOT flag requests that the peripheral assert an end of transaction interrupt
when that descriptor is complete. It also results in special signaling protocol
that is used between the
On 30 May 2014 22:12, Mimi Zohar wrote:
> On Fri, 2014-05-30 at 21:24 +0300, Dmitry Kasatkin wrote:
>> On 30 May 2014 20:58, "Mimi Zohar" wrote:
>> >
>> > On Fri, 2014-05-30 at 18:58 +0300, Dmitry Kasatkin wrote:
>> > > On 28 May 2014 18:09, Mimi Zohar wrote:
>> > > > Dot prefixed keyring names
On May 29, 2014, at 8:41 PM, Liviu Dudau wrote:
> On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
>> On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau wrote:
>>> On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring wrote:
On May 30, 2014, at 3:37 PM, Jason Gunthorpe
wrote:
> On Fri, May 30, 2014 at 02:41:17AM +0100, Liviu Dudau wrote:
>
>> Agree, I'm only concerned that if this ECAM config space gets added to
>> the list of pci_host_bridge windows it will be indistinguishable from
>> IORESOURCE_MEM resources
tty, usbgadgetfs, configfs and cramfs do not store inode timestamps
permanently, but they use code that interacts with the VFS inode
times. In order to change over VFS to a struct inode_time, we
have to make trivial changes to these file systems as well.
Signed-off-by: Arnd Bergmann
Cc: Greg
logfs uses 64-bit integers for inode timestamps, which will work
for the next 550 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in logfs.
Signed-off-by:
On Fri, May 30, 2014 at 02:41:17AM +0100, Liviu Dudau wrote:
> Agree, I'm only concerned that if this ECAM config space gets added to
> the list of pci_host_bridge windows it will be indistinguishable from
> IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
> bus and allow
On Fri, May 30, 2014 at 1:20 PM, H. Peter Anvin wrote:
> On 05/30/2014 01:11 PM, Andy Lutomirski wrote:
>> On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote:
>>> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
Do the flags go in the ELF loader or in the executable we're running?
On Fri, May 30, 2014 at 1:21 PM, H. Peter Anvin wrote:
> On 05/30/2014 01:09 PM, Andy Lutomirski wrote:
>>>
>>> I came up with the following, it seems like a reasonable simplification:
>>>
#define _LE(x, bits, ifnot) \
Currently iter_file_splice_write pushes into the output IOVs as much
as it can, so that if one previously pushed into pipe 8K of data and
then try to fetch 4K -- he get the complete 8K instead.
Lest count how many bytes were requested by a caller and
stop looping once request is complete.
Hi guys,
now that there will be -rc8, we don't need to delay those for 3.17, so
please pull.
Thanks.
The following changes since commit c7208164e66f63e3ec1759b98087849286410741:
Linux 3.15-rc7 (2014-05-25 16:06:00 -0700)
are available in the git repository at:
On 05/30/2014 01:09 PM, Andy Lutomirski wrote:
>>
>> I came up with the following, it seems like a reasonable simplification:
>>
>>> #define _LE(x, bits, ifnot) \
>>> __builtin_choose_expr( \
>>>
On 05/30/2014 01:11 PM, Andy Lutomirski wrote:
> On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote:
>> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
>>>
>>> Do the flags go in the ELF loader or in the executable we're running?
>>> Or both (and, if both, do we and them or or them)?
>>>
>>> I
On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> We cannot use time_t or any derived structures beyond the year
> 2038 in interfaces between kernel and user space, on 32-bit
> machines.
>
> This is my suggestion for how to migrate syscall and ioctl
> interfaces: We completely phase out time_t,
ext3fs uses unsigned 32-bit seconds for inode timestamps, which will work
for the next 92 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in ext3. The
This introduces a new variant of the utime/utimes/futimesat/utimensat
system call (used by /usr/bin/touch), which fixes the 32-bit limitation
of time_t at the kernel/user boundary for 32-bit machines.
Each of the variants is a strict superset of the functionality of the
previous ones, so we only
pstore uses timestamps encoded in a string as seconds, but on 32-bit systems
cannot go beyond year 2038 because of the limits of struct timespec.
This converts the pstore code to use the new struct inode_time for timestamps.
Signed-off-by: Arnd Bergmann
Cc: Anton Vorontsov
Cc: Colin Cross
Cc:
As one part of the puzzle to solve the y2038 problem, this introduces
a new time type to be used for keeping inode timestamps (atime, ctime,
mtime) inside of the kernel.
Initially, this type is defined to 'struct timespec' to allow migrating
all file systems one by one, but the intention is to
Up to 7 bytes are wasted at the end of struct platform_object
in the form of padding after name field: unfortunately this
padding is not used when allocating the memory to hold the
name.
This patch converts name array from name[1] to C99 flexible
array name[] (equivalent to name[0]) so that no
ext4fs uses unsigned 34-bit seconds for inode timestamps, which will work
for the next 500 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in ext4.
isofs uses a 'char' variable to load the number of years since
1900 for an inode timestamp. On architectures that use a signed
char type by default, this results in an invalid date for
anything beyond 2027.
This adds a cast to 'u8' for the year number, which should extend
the shelf life of the
ntfs uses 64-bit integers for inode timestamps, which will work
thousands of years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in ntfs.
Signed-off-by: Arnd
btrfs uses unsigned 64-bit seconds for inode timestamps, which will work
basically forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in btrfs.
On 05/30/2014 01:07 PM, Tim Chen wrote:
On Fri, 2014-05-30 at 12:38 -0700, Dirk Brandewie wrote:
Dirk,
Thanks for checking things out.
I tested on a Haswell system, and I see that the frequency
can dip below the max even when I set the min_perf_pct to 100.
Let me know if you want to log on
We cannot use time_t or any derived structures beyond the year
2038 in interfaces between kernel and user space, on 32-bit
machines.
This is my suggestion for how to migrate syscall and ioctl
interfaces: We completely phase out time_t, timeval and timespec
from the uapi header files and replace
adfs uses unsigned 40-bit seconds for inode timestamps, which will work
for the next 234 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in adfs.
jffs2 uses unsigned 32-bit seconds for inode timestamps, which will work
for the next 92 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in jffs2.
hfs uses 32-bit integers based at 1904 for inode timestamps, which will
only work until 2040, but the VFS uses struct timespec for timestamps,
which expires even earlier in 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in logfs.
After all file systems have been converted to use 'struct inode_time'
for timestamps, we can remove the compatibility definition for this
structure.
This patch picks the first of the three variants I defined, but we
could pick one of the others as well.
Signed-off-by: Arnd Bergmann
---
reiserfs uses unsigned 32-bit seconds for inode timestamps, which will work
for the next 92 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in reiserfs.
This changelog doesn't match the patch.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
The fnic driver currently uses the CURRENT_TIME macro to
generate a timestamp. Since this is otherwise used only in
file system code and we want to change the type, it's
better for this driver to use the equivalent function that
continues to return a struct timespec.
Signed-off-by: Arnd Bergmann
On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin wrote:
> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
>>
>> Do the flags go in the ELF loader or in the executable we're running?
>> Or both (and, if both, do we and them or or them)?
>>
>> I think the interpreter makes a little more sense in
f2fs uses unsigned 40-bit seconds for inode timestamps, which will work
basically forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in f2fs.
Signed-off-by:
fuse uses 64-bit seconds for inode timestamps in the user interface,
which will work basically forever, but the VFS uses struct timespec
for timestamps, which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in fuse.
Different arches may have different cacheline sizes. Look it up and set
a global variable for reference.
Signed-off-by: Don Zickus
---
V4: make it super simple using a sysconf (Arnaldo)
V3: remove unneeded cpumap.h (Namhyung Kim)
V2: change to be global and setup in perf.c
use
gfs2 uses 64-bit integers for inode timestamps, which will work
basically forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in gfs2.
Signed-off-by: Arnd
On Fri, 2014-05-30 at 12:38 -0700, Dirk Brandewie wrote:
> > Dirk,
> >
> > Thanks for checking things out.
> >
> > I tested on a Haswell system, and I see that the frequency
> > can dip below the max even when I set the min_perf_pct to 100.
> > Let me know if you want to log on to my system and
This makes the nfs client and server code use 'struct inode_time'
instead of 'struct timespec', to lift the time stamp limitation
on 32-bit systems. With NFS version 2 and 3, this means we can
represent years up until 2106 rather than 2038. With NFS version
4, the on-wire representation allows
On 30 May 2014 21:45, Nicolas Pitre wrote:
> On Fri, 30 May 2014, Vincent Guittot wrote:
>
>> On 30 May 2014 15:26, Dietmar Eggemann wrote:
>> >> + /*
>> >> + * The group capacity is reduced probably because of activity from
>> >> other
>> >
>> > Here 'group capacity' refers to
On Fri, May 30, 2014 at 1:02 PM, H. Peter Anvin wrote:
> On 05/30/2014 08:48 AM, Andy Lutomirski wrote:
>> This adds a macro GET(x) to convert x from big-endian to
>> little-endian. Hopefully I put it everywhere it needs to go and got
>> all the cases needed for everyone's linux/elf.h.
>>
>>
ocfs2 uses unsigned 34-bit seconds for inode timestamps, which will work
for the next 500 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in ocfs2.
ubifs uses 64-bit integers for inode timestamps, which will work
practicall forever, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in ubifs.
Signed-off-by: Arnd
fat uses 7-bit year numbers for inode timestamps, which will work
for the next 93 years, but the VFS uses struct timespec for timestamps,
which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time in fat.
Signed-off-by:
Based on the recent discussion about 64-bit time_t for new
architectures, and for solving the year 2038 problem in general,
I decided to try out what it would take to solve part of the
kernel side of things.
This is a proof-of-concept work to get us to the point where
two system calls (utimes and
This adds the newly added system calls for newfstat64, newfstatat64
and utimens64at to x86, arm and all architectures using the generic
syscall ABI.
Signed-off-by: Arnd Bergmann
---
arch/arm/include/asm/unistd.h | 2 +-
arch/arm/include/uapi/asm/stat.h | 25 +
We want to be able to read file system timestamps beyond year 2038,
which is currently impossibly on 32-bit systems, since none of the
various stat syscall interfaces (oldstat, stat, stat64) handles
correctly.
This introduces a fourth version of the syscalls, called newfstat64
and newfstatat64,
afs uses an unsigned 32-bit seconds numbers for inode timestamps on the
wire, which will work for the next 92 years, but the code internally
uses a signed time_t, which is only good until 2038 on 32-bit CPUs.
This gets us one small step closer to lifting the VFS limit by using
struct inode_time
This converts the coda file system to use inode_time, which we will
need to fix the y2038 limit. However, inode time stamps in coda
are communicated to user space through coda_pioctl() as a 'struct
timespec', so this cannot be fixed for coda without changing the
user space interface.
101 - 200 of 1446 matches
Mail list logo
