Dear Recipent ,
This email address has won Three Million Pounds on the o2 mobile sweepstakes.Please Contact Payment Cordinator Mat on email : mrwest(a)o2loto.co.uk for explanation and payment processing .
Yours Faithfully
Debbie Spence
Cordinator O2 Mobile Promotional Sweepstakes.
Hi everyone,
As I discussed with Thomas on IRC, I'd still like to try to get Deepa's series
merged to have 64-bit inode timestamps in VFS, as a prerequisite to fixing
the individual file systems for y2038 as the next step.
The orignal tree that I've been testing with is in
https://github.com/deepa-hub/vfs vfs_timespec64 (see description at [1]
Unfortunately this was never in linux-next so far, so it's definitely
against our
normal rules, and if there are any objections (or new issues getting found),
then we should defer it another merge window.
Until very recently, the branch worked fine with both linux-next and 4.17-rc,
but with some last minute changes to the NFS and Overlayfs trees, it
gained some nasty conflicts.
I've merged Trond's NFS branch and Miklos' Overlayfs branches into
it, fixed up those conflicts and now uploaded it to my tree at
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
Obviously this will break if either of them rebases their trees once
more, in which case I assume Stephen will drop my branch from
linux-next.
Once those two are merged into mainline and nothing unexpected
has come up from linux-next testing, we could either send a pull request
to Linus for the merged branch, or regenerate the flag-day patch in it
using coccinelle, which should result in identical contents.
Arnd
[1] https://lkml.org/lkml/2018/5/25/828
In order to use the rtc_tm_to_time64() and rtc_time64_to_tm()
helper functions in later patches, we have to ensure that
CONFIG_RTC_LIB is always built-in.
Note that this symbol only controls a couple of helper functions,
not the actual RTC subsystem, which remains optional and is
enabled with CONFIG_RTC_CLASS.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c32a181a7cbb..de2cda320fdd 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -232,6 +232,7 @@ config PPC
select OF_RESERVED_MEM
select OLD_SIGACTION if PPC32
select OLD_SIGSUSPEND
+ select RTC_LIB
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS if !PPC64
--
2.9.0
Hi Thomas,
This is a pull request for the series that I sent earlier.
The series aims to switch vfs timestamps to use
struct timespec64. Currently vfs uses struct timespec,
which is not y2038 safe.
The flag patch applies cleanly. I've not seen the timestamps
update logic change often. The series applies cleanly on 4.17-rc6
and linux-next tip (top commit: next-20180517).
I'm not sure how to merge this kind of a series with a flag patch.
We are targeting 4.18 for this.
Let me know if you have other suggestions.
The series involves the following:
1. Add vfs helper functions for supporting struct timepec64 timestamps.
2. Cast prints of vfs timestamps to avoid warnings after the switch.
3. Simplify code using vfs timestamps so that the actual
replacement becomes easy.
4. Convert vfs timestamps to use struct timespec64 using a script.
This is a flag day patch.
I've tried to keep the conversions with the script simple, to
aid in the reviews. I've kept all the internal filesystem data
structures and function signatures the same.
Next steps:
1. Convert APIs that can handle timespec64, instead of converting
timestamps at the boundaries.
2. Update internal data structures to avoid timestamp conversions.
--
Changes from v1:
* Fix the pointer bug in the udf patch.
* Include Kees's patch for pstore.
* Fix hostfs regression found by kbuild bot.
The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11:
Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)
are available in the Git repository at:
https://github.com/deepa-hub/vfs vfs_timespec64
for you to fetch changes up to 213ae530f442029284ab6041812df0571ebd9da7:
vfs: change inode times to use struct timespec64 (2018-05-25 15:31:14 -0700)
----------------------------------------------------------------
Deepa Dinamani (6):
fs: add timespec64_truncate()
lustre: Use long long type to print inode time
ceph: make inode time prints to be long long
fs: nfs: get rid of memcpys for inode times
udf: Simplify calls to udf_disk_stamp_to_time
vfs: change inode times to use struct timespec64
Kees Cook (1):
pstore: Convert internal records to timespec64
drivers/firmware/efi/efi-pstore.c | 27 ++++----
drivers/staging/lustre/lustre/llite/llite_lib.c | 12 ++--
drivers/staging/lustre/lustre/llite/namei.c | 5 +-
drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 +-
drivers/staging/lustre/lustre/mdc/mdc_reint.c | 6 +-
drivers/staging/lustre/lustre/obdclass/obdo.c | 6 +-
drivers/tty/tty_io.c | 15 ++++-
drivers/usb/gadget/function/f_fs.c | 2 +-
fs/adfs/inode.c | 7 +-
fs/afs/fsclient.c | 2 +-
fs/attr.c | 14 ++--
fs/bad_inode.c | 2 +-
fs/btrfs/file.c | 6 +-
fs/btrfs/inode.c | 8 +--
fs/btrfs/ioctl.c | 4 +-
fs/btrfs/root-tree.c | 4 +-
fs/btrfs/transaction.c | 2 +-
fs/ceph/addr.c | 12 ++--
fs/ceph/cache.c | 4 +-
fs/ceph/caps.c | 6 +-
fs/ceph/file.c | 6 +-
fs/ceph/inode.c | 86 +++++++++++++------------
fs/ceph/mds_client.c | 7 +-
fs/ceph/snap.c | 6 +-
fs/cifs/cache.c | 4 +-
fs/cifs/fscache.c | 8 +--
fs/cifs/inode.c | 26 ++++----
fs/coda/coda_linux.c | 12 ++--
fs/configfs/inode.c | 12 ++--
fs/cramfs/inode.c | 2 +-
fs/ext4/ext4.h | 34 ++++++----
fs/ext4/ialloc.c | 4 +-
fs/ext4/namei.c | 2 +-
fs/f2fs/f2fs.h | 10 ++-
fs/f2fs/file.c | 12 ++--
fs/f2fs/inode.c | 12 ++--
fs/f2fs/namei.c | 4 +-
fs/fat/inode.c | 20 ++++--
fs/fat/namei_msdos.c | 21 +++---
fs/fat/namei_vfat.c | 22 ++++---
fs/fuse/inode.c | 2 +-
fs/gfs2/dir.c | 6 +-
fs/gfs2/glops.c | 4 +-
fs/hfs/inode.c | 4 +-
fs/hfsplus/inode.c | 12 ++--
fs/hostfs/hostfs_kern.c | 12 ++--
fs/inode.c | 58 ++++++++++++-----
fs/jffs2/dir.c | 18 +++---
fs/jffs2/file.c | 2 +-
fs/jffs2/fs.c | 12 ++--
fs/kernfs/dir.c | 4 +-
fs/kernfs/inode.c | 8 +--
fs/locks.c | 2 +-
fs/nfs/callback_proc.c | 4 +-
fs/nfs/fscache-index.c | 4 +-
fs/nfs/fscache.c | 12 ++--
fs/nfs/inode.c | 39 ++++++-----
fs/nfs/nfs2xdr.c | 25 ++++---
fs/nfs/nfs3xdr.c | 8 ++-
fs/nfs/nfs4xdr.c | 7 +-
fs/nfsd/blocklayout.c | 8 ++-
fs/nfsd/nfs3xdr.c | 14 ++--
fs/nfsd/nfs4xdr.c | 7 +-
fs/nfsd/nfsxdr.c | 2 +-
fs/ntfs/inode.c | 30 ++++-----
fs/ocfs2/dlmglue.c | 20 ++++--
fs/ocfs2/file.c | 6 +-
fs/orangefs/inode.c | 2 +-
fs/orangefs/orangefs-kernel.h | 2 +-
fs/overlayfs/inode.c | 2 +-
fs/overlayfs/overlayfs.h | 2 +-
fs/proc/uptime.c | 2 +-
fs/pstore/platform.c | 2 +-
fs/pstore/ram.c | 21 ++++--
fs/reiserfs/namei.c | 2 +-
fs/reiserfs/xattr.c | 4 +-
fs/ubifs/dir.c | 4 +-
fs/ubifs/file.c | 23 +++----
fs/ubifs/ubifs.h | 2 +-
fs/udf/ialloc.c | 4 +-
fs/udf/inode.c | 59 +++++++++--------
fs/udf/super.c | 17 +++--
fs/udf/udfdecl.h | 4 +-
fs/udf/udftime.c | 9 +--
fs/xfs/xfs_inode.c | 2 +-
fs/xfs/xfs_iops.c | 2 +-
fs/xfs/xfs_trans_inode.c | 2 +-
include/linux/fs.h | 24 +++----
include/linux/pstore.h | 2 +-
include/linux/stat.h | 8 +--
90 files changed, 558 insertions(+), 434 deletions(-)
--
2.17.0
The pstore conversion to timespec64 introduces its own method of passing
seconds into sscanf() and sprintf() type functions to work around the
timespec64 definition on 64-bit systems that redefine it to 'timespec'.
That hack is now finally getting removed, but that means we get a (harmless)
warning once both patches are merged:
fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr':
fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=]
#define RAMOOPS_KERNMSG_HDR "===="
^~~~~~
fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
This removes the pstore specific workaround and uses the same method that
we have in place for all other functions that print a timespec64.
Related to this, I found that the kasprintf() output contains an incorrect
nanosecond values for any number starting with zeroes, and I adapt the
format string accordingly.
Link: https://lkml.org/lkml/2018/5/19/115
Link: https://lkml.org/lkml/2018/5/16/1080
Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
fs/pstore/ram.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 69e893076ab7..bbd1e357c23d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -38,11 +38,6 @@
#define RAMOOPS_KERNMSG_HDR "===="
#define MIN_MEM_SIZE 4096UL
-#if __BITS_PER_LONG == 64
-# define TVSEC_FMT "%ld"
-#else
-# define TVSEC_FMT "%lld"
-#endif
static ulong record_size = MIN_MEM_SIZE;
module_param(record_size, ulong, 0400);
@@ -164,15 +159,15 @@ static int ramoops_read_kmsg_hdr(char *buffer, struct timespec64 *time,
char data_type;
int header_length = 0;
- if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n%n",
- &time->tv_sec, &time->tv_nsec, &data_type,
+ if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu-%c\n%n",
+ (time64_t *)&time->tv_sec, &time->tv_nsec, &data_type,
&header_length) == 3) {
if (data_type == 'C')
*compressed = true;
else
*compressed = false;
- } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu\n%n",
- &time->tv_sec, &time->tv_nsec,
+ } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu\n%n",
+ (time64_t *)&time->tv_sec, &time->tv_nsec,
&header_length) == 2) {
*compressed = false;
} else {
@@ -367,8 +362,8 @@ static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz,
char *hdr;
size_t len;
- hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n",
- record->time.tv_sec,
+ hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR "%lld.%06lu-%c\n",
+ (time64_t)record->time.tv_sec,
record->time.tv_nsec / 1000,
record->compressed ? 'C' : 'D');
WARN_ON_ONCE(!hdr);
--
2.9.0
<div dir="ltr"><p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Hi,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Hope this
note finds you well!</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Would you
be interested in <b>Point Of Sale Software Users List</b>? We are a Global
Technology
User’s List Provider’s with 90 Million Plus data and counting.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">It is good
if you keep track of all your competitors'
movements and their campaign strategies. But do not make their strategies of
your own; you can never beat them that way. Even if the industry is the
same,
each organization has some specific business goals in mind that requires a
campaign-plan that is different from others. Considering the fact that data
requirement for every marketer will be non-identical as per their campaign
planning, we at first consult with our clients to understand their
strategies
and then tailor personalized <b>list of
companies using POS software </b>accordingly<b>.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Do not
hesitate to take the smart step for improving your
business. Deliver highly targeted campaign to your customers and prospects
using the comprehensive <b>Retail
Management (POS) Software user</b> group’s data, drive the right traffic to
your website and <b>generate quality leads
through targeted b2b marketing.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">By
partnering with us you can obtain an effective email
list of Point of Sale software customers, where each record comes with
<b>full contact name, complete postal address,
mobile telephone number and email addresses, and much more.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Please let
us know your targeted criteria and geography to
provide you with detailed information for your review.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Let me
know your thoughts!</span></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Thanks,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><font color="#1f4e79"><b>Jacinta
Martin</b></font></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Senior
Database Executive</span></b></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(156,194,229)">
To “opt out” response not interested<span></span></span></p>
<p class="MsoNormal"><span> </span></p></div>
<p> </p><a style='display: block; margin: 32px 0 40px 0; padding:
10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid
gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and
email marketing software for Gmail.</a>
